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.

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.

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

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.

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.

A use-after-free vulnerability was discovered in BusyBox v.1.36.1 via a crafted awk pattern in the awk.c copyvar function.

A use-after-free vulnerability in BusyBox v.1.36.1 allows attackers to cause a denial of service via a crafted awk pattern in the awk.c evaluate function.

Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. In versions on the 4.x branch prior to version 4.0.5, when parsing compact JWS or JWE input, Go JOSE could use excessive memory. The code used strings.Split(token, ".") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of `.` characters.  An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service. Version 4.0.5 fixes this issue. As a workaround, applications could pre-validate that payloads passed to Go JOSE do not contain an excessive number of `.` characters.

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

ghcr.io/l3montree-dev/devguard

main

Devguard-Pipeline

quay.io/jetstack/cert-manager-acmesolver

ghcr.io/l3montree-dev/devguard-operator

ghcr.io/l3montree-dev/devguard-postgresql

devguard-action

docker.io/oryd/kratos

 Devguard-Pipeline

devguard-web

DevGuard Operator

devguard-scanner

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

devguard-bot-dev[bot]

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 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 scanner component of the devguard project

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
alpine/musl	3.6	3.6	1	1.2.5-r0	No fix available
github.com/golang-jwt/jwt/v4	3.5	3.5	1	4.5.1	Update to version 4.5.2 to reduce total risk by 3.5
alpine/openssl	3.5	5.5	4	3.3.1-r3	No fix available
golang.org/x/crypto	3.5	3.5	1	0.32.0	Update to version 0.35.0 to reduce total risk by 3.5
alpine/busybox	2.5	5.1	2	1.36.1-r29	No fix available
github.com/go-jose/go-jose/v4	0.0	0.0	1	4.0.4	Update to version 4.0.5 to reduce total risk by 0.0
golang.org/x/net	0.0	0.0	1	0.34.0	Update to version 0.36.0 to reduce total risk by 0.0
stdlib	0.0	0.0	1	1.24.0	Update to version 1.24.2 to reduce total risk by 0.0

L3montree Cybersecurity
Organization
/Devguard
Project
/ghcr.io/l3montree-dev/devguard
Asset

Identified Risks