Moby is an open-source project created by Docker to enable software containerization. The classic builder cache system is prone to cache poisoning if the image is built FROM scratch. Also, changes to some instructions (most important being HEALTHCHECK and ONBUILD) would not cause a cache miss. An attacker with the knowledge of the Dockerfile someone is using could poison their cache by making them pull a specially crafted image that would be considered as a valid cache candidate for some build steps. 23.0+ users are only affected if they explicitly opted out of Buildkit (DOCKER_BUILDKIT=0 environment variable) or are using the /build API endpoint. All users on versions older than 23.0 could be impacted. Image build API endpoint (/build) and ImageBuild function from github.com/docker/docker/client is also affected as it the uses classic builder by default. Patches are included in 24.0.9 and 25.0.2 releases.

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.

The various Is methods (IsPrivate, IsLoopback, etc) did not work as expected for IPv4-mapped IPv6 addresses, returning false for addresses which would return true in their traditional IPv4 forms.

The archive/zip package's handling of certain types of invalid zip files differs from the behavior of most zip implementations. This misalignment could be exploited to create an zip file with contents that vary depending on the implementation reading the file. The archive/zip package now rejects files containing these errors.

The net/http HTTP/1.1 client mishandled the case where a server responds to a request with an "Expect: 100-continue" header with a non-informational (200 or higher) status. This mishandling could leave a client connection in an invalid state, where the next request sent on the connection will fail. An attacker sending a request to a net/http/httputil.ReverseProxy proxy can exploit this mishandling to cause a denial of service by sending "Expect: 100-continue" requests which elicit a non-informational response from the backend. Each such request leaves the proxy with an invalid connection, and causes one subsequent request using that connection to fail.

An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.

Due to the usage of a variable time instruction in the assembly implementation of an internal function, a small number of bits of secret scalars are leaked on the ppc64le architecture. Due to the way this function is used, we do not believe this leakage is enough to allow recovery of the private key when P-256 is used in any well known protocols.

Calling Parse on a "// +build" build tag line with deeply nested expressions can cause a panic due to stack exhaustion.

Calling Decoder.Decode on a message which contains deeply nested structures can cause a panic due to stack exhaustion. This is a follow-up to CVE-2022-30635.

Uncontrolled recursion in Decoder.Decode in encoding/gob before Go 1.17.12 and Go 1.18.4 allows an attacker to cause a panic due to stack exhaustion via a message which contains deeply nested structures.

Calling any of the Parse functions on Go source code which contains deeply nested literals can cause a panic due to stack exhaustion.

go-git is a highly extensible git implementation library written in pure Go. An argument injection vulnerability was discovered in go-git versions prior to v5.13. Successful exploitation of this vulnerability could allow an attacker to set arbitrary values to git-upload-pack flags. This only happens when the file transport protocol is being used, as that is the only protocol that shells out to git binaries. This vulnerability is fixed in 5.13.0.

go-git is a highly extensible git implementation library written in pure Go. A denial of service (DoS) vulnerability was discovered in go-git versions prior to v5.13. This vulnerability allows an attacker to perform denial of service attacks by providing specially crafted responses from a Git server which triggers resource exhaustion in go-git clients. Users running versions of go-git from v4 and above are recommended to upgrade to v5.13 in order to mitigate this vulnerability.

An issue was discovered in Cloud Native Computing Foundation (CNCF) Helm through 3.13.3. It displays values of secrets when the --dry-run flag is used. This is a security concern in some use cases, such as a --dry-run call by a CI/CD tool. NOTE: the vendor's position is that this behavior was introduced intentionally, and cannot be removed without breaking backwards compatibility (some users may be relying on these values). Also, it is not the Helm Project's responsibility if a user decides to use --dry-run within a CI/CD environment whose output is visible to unauthorized persons.

Issue summary: Applications performing certificate name checks (e.g., TLS
clients checking server certificates) may attempt to read an invalid memory
address resulting in abnormal termination of the application process.

Impact summary: Abnormal termination of an application can a cause a denial of
service.

Applications performing certificate name checks (e.g., TLS clients checking
server certificates) may attempt to read an invalid memory address when
comparing the expected name with an `otherName` subject alternative name of an
X.509 certificate. This may result in an exception that terminates the
application program.

Note that basic certificate chain validation (signatures, dates, ...) is not
affected, the denial of service can occur only when the application also
specifies an expected DNS name, Email address or IP address.

TLS servers rarely solicit client certificates, and even when they do, they
generally don't perform a name check against a reference identifier (expected
identity), but rather extract the presented identity after checking the
certificate chain.  So TLS servers are generally not affected and the severity
of the issue is Moderate.

The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrusted
explicit values for the field polynomial can lead to out-of-bounds memory reads
or writes.

Impact summary: Out of bound memory writes can lead to an application crash or
even a possibility of a remote code execution, however, in all the protocols
involving Elliptic Curve Cryptography that we're aware of, either only "named
curves" are supported, or, if explicit curve parameters are supported, they
specify an X9.62 encoding of binary (GF(2^m)) curves that can't represent
problematic input values. Thus the likelihood of existence of a vulnerable
application is low.

In particular, the X9.62 encoding is used for ECC keys in X.509 certificates,
so problematic inputs cannot occur in the context of processing X.509
certificates.  Any problematic use-cases would have to be using an "exotic"
curve encoding.

The affected APIs include: EC_GROUP_new_curve_GF2m(), EC_GROUP_new_from_params(),
and various supporting BN_GF2m_*() functions.

Applications working with "exotic" explicit binary (GF(2^m)) curve parameters,
that make it possible to represent invalid field polynomials with a zero
constant term, via the above or similar APIs, may terminate abruptly as a
result of reading or writing outside of array bounds.  Remote code execution
cannot easily be ruled out.

The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

Issue summary: A timing side-channel which could potentially allow recovering
the private key exists in the ECDSA signature computation.

Impact summary: A timing side-channel in ECDSA signature computations
could allow recovering the private key by an attacker. However, measuring
the timing would require either local access to the signing application or
a very fast network connection with low latency.

There is a timing signal of around 300 nanoseconds when the top word of
the inverted ECDSA nonce value is zero. This can happen with significant
probability only for some of the supported elliptic curves. In particular
the NIST P-521 curve is affected. To be able to measure this leak, the attacker
process must either be located in the same physical computer or must
have a very fast network connection with low latency. For that reason
the severity of this vulnerability is Low.

Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a
server may fail to notice that the server was not authenticated, because
handshakes don't abort as expected when the SSL_VERIFY_PEER verification mode
is set.

Impact summary: TLS and DTLS connections using raw public keys may be
vulnerable to man-in-middle attacks when server authentication failure is not
detected by clients.

RPKs are disabled by default in both TLS clients and TLS servers.  The issue
only arises when TLS clients explicitly enable RPK use by the server, and the
server, likewise, enables sending of an RPK instead of an X.509 certificate
chain.  The affected clients are those that then rely on the handshake to
fail when the server's RPK fails to match one of the expected public keys,
by setting the verification mode to SSL_VERIFY_PEER.

Clients that enable server-side raw public keys can still find out that raw
public key verification failed by calling SSL_get_verify_result(), and those
that do, and take appropriate action, are not affected.  This issue was
introduced in the initial implementation of RPK support in OpenSSL 3.2.

The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

musl libc 0.9.13 through 1.2.5 before 1.2.6 has an out-of-bounds write vulnerability when an attacker can trigger iconv conversion of untrusted EUC-KR text to UTF-8.

containerd is an open-source container runtime. A bug was found in containerd prior to versions 1.6.38, 1.7.27, and 2.0.4 where containers launched with a User set as a `UID:GID` larger than the maximum 32-bit signed integer can cause an overflow condition where the container ultimately runs as root (UID 0). This could cause unexpected behavior for environments that require containers to run as a non-root user. This bug has been fixed in containerd 1.6.38, 1.7.27, and 2.04. As a workaround, ensure that only trusted images are used and that only trusted users have permissions to import images.

SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.

golang-jwt is a Go implementation of JSON Web Tokens. Prior to 
5.2.2 and 4.5.2, the function parse.ParseUnverified splits (via a call to strings.Split) its argument (which is untrusted data) on periods. As a result, in the face of a malicious request whose Authorization header consists of Bearer  followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. This issue is fixed in 5.2.2 and 4.5.2.

An attacker can pass a malicious malformed token which causes unexpected memory to be consumed during parsing.

The scanner component of the devguard project

devguard-scanner

437-error-in-devguard-deploy-step

274-handleevent-crashes-with-first-party-vulnerabilities-in-githubgitlab-integration

fix/tag-or-branche-function

fix-bugs

main

426-update-and-close-tickets-in-risk-daemon

postgres-cycle-detection

fix/latestTag-name

HEAD

add-api-url

264-delete-asset-version

fix/risk-recalculated-time

360-devguard-scanner-link-is-incorrect

fix/event-query

0.8.3 386-change-the-dependency-vulns-table-to-be-able-to-have-multiple-scanner-ids

365-multiple-instances-of-the-same-cve-in-an-asset

fix/test-names

l3monKenji-patch-2

sarif-endpoint-new

262-remove-projects

258-unable-to-create-organization-with-an-existing-name

356-only-automatically-create-tickets-if-there-is-no-other-asset-version-with-an-already-created-ticket-for-this-vulnerability

251-button-to-upload-an-sbom-manually

0.9.0 388-automatic-ticket-creation-creates-tickets-for-already-accepted-vulnerabilities

idea/simplifies-interfaces

325-rename-certain-things-to-make-them-more-clear

feature/rego-eval

293-allow-users-to-specify-access-scope-when-generating-personal-access-tokens

282-whole-system-crash-when-sending-empty-gitlab-string

266-remove-possible-double-slash-in-terminal-output-after-scanning-an-asset

fix/needed-scope

feature/deps.dev

358-webhook-doesnt-work-anymore

test-branch

267-cannot-create-new-asset-version-after-deleting-one-with-the-same-name

294-devguard-scanner-does-not-panic-we-need-to-recheck-all-and-we-need-some-more-thouroughly-testing

fix/vuln-event-query

fix/create-assetversion-bug

298-fix-gitlab-webhook-integration

feature/code-coverage-report

fix/raw-riskassessment-values

289-automatically-create-ticket-for-high-risk-or-or-high-cvss-vulnerabilities

0.9.1

0.8.2 277-install-gitleaks-and-semgrep-in-dockerfilescanner

chore/improve-helm-chart-web-component

291-fix-asset-version-name-in-events

364-add-dependency-graph-to-github-and-gitlab-tickets-using-mermaidjs

249-devguard-scanner-should-panic-if-error-occurs

362-risk-handling-table-does-not-filter-anymore

269-improve-auto-setup-use-dynamic-api-and-webhook-urls-for-gitlab-integration

361-unknown-created-the-ticket

l3monKenji-patch-1

328-add-attestations-to-each-asset-version

310-server-stuck-in-loop-when-updating-an-organization-name-to-an-empty-name

fix/remove-test-json

363-dependency-graph-endpoint

chore/remove-version-from-components

Devguard-Pipeline

quay.io/jetstack/cert-manager-acmesolver

ghcr.io/l3montree-dev/devguard-operator

ghcr.io/l3montree-dev/devguard-postgresql

devguard-action

ghcr.io/l3montree-dev/devguard

docker.io/oryd/kratos

 Devguard-Pipeline

DevGuard Operator

devguard-web

devguard-documentation

Devguard Postgresql

devguard

Devguard

Robot User

OpenCoDE

Lars Hermges

Patrick Rissmann

Sebastian Kawelke

Tim Bastin

Refaei Shikho

Frédéric Noppe

refoo0

l3montree-robot

timbastin

seb-kw

L3montree Cybersecurity

Controlled by an Kubernetes Operator. Asset ghcr.io/l3montree-dev/devguard-operator

Controlled by an Kubernetes Operator. Asset ghcr.io/l3montree-dev/devguard-postgresql

Controlled by an Kubernetes Operator. Asset ghcr.io/l3montree-dev/devguard

Controlled by an Kubernetes Operator. Asset docker.io/oryd/kratos

This is a scan for Devguard CI/CD components in a GitLab project, aimed at testing whether these components function correctly.

The documentation for the DevGuard Project

Manage your CVEs seamlessly, Integrate your Vulnerability Scanners, Documentation made easy, Compliance to security Frameworks - OWASP Incubating Project

Package	Max Risk	Total Risk	Flaw Count	Installed Version	Action
github.com/docker/docker	4.7	8.3	2	24.0.0	Update to version 25.0.6+incompatible to reduce total risk by 8.3
stdlib	4.5	22.6	12	1.21.8	Update to version 1.23.8 to reduce total risk by 22.6
github.com/go-git/go-git/v5	4.5	7.1	2	5.12.0	Update to version 5.13.0 to reduce total risk by 7.1
helm.sh/helm/v3	4.5	4.5	1	3.16.3	No fix available
alpine/openssl	4.3	6.5	4	3.3.1-r3	No fix available
alpine/musl	3.8	3.8	1	1.2.5-r0	No fix available
github.com/containerd/containerd	2.7	2.7	1	1.7.23	Update to version 1.7.27 to reduce total risk by 2.7
github.com/containerd/containerd/v2	2.7	2.7	1	2.0.0	Update to version 2.0.4 to reduce total risk by 2.7
golang.org/x/crypto	2.6	2.6	1	0.31.0	Update to version 0.35.0 to reduce total risk by 2.6
github.com/golang-jwt/jwt/v4	2.6	2.6	1	4.5.1	Update to version 4.5.2 to reduce total risk by 2.6
golang.org/x/oauth2	2.6	2.6	1	0.22.0	Update to version 0.27.0 to reduce total risk by 2.6
golang.org/x/oauth2	2.6	2.6	1	0.25.0	Update to version 0.27.0 to reduce total risk by 2.6
github.com/golang-jwt/jwt/v5	2.6	2.6	1	5.2.1	Update to version 5.2.2 to reduce total risk by 2.6
golang.org/x/crypto	2.6	2.6	1	0.32.0	Update to version 0.35.0 to reduce total risk by 2.6

L3montree Cybersecurity
Organization
/Devguard
Project
/devguard-scanner
Asset

Identified Risks