A flaw was found in Moodle. An authorization logic flaw, specifically due to incomplete role checks during the badge awarding process, allowed badges to be granted without proper verification. This could enable unauthorized users to obtain badges they are not entitled to, potentially leading to privilege escalation or unauthorized access to certain features.
Kyverno versions prior to 1.15.3 and versions from 1.16.0 up to but not including 1.16.3 contain a vulnerability in the policy engine that allows users with policy creation privileges to cause denial of service by crafting policies that exponentially amplify string data via context variables, leading to unbounded memory consumption. This issue is patched in versions 1.15.3 and 1.16.3.
A vulnerability in PyTorch prior to version 2.10.0 allows remote attackers to execute arbitrary code by crafting malicious checkpoint files (.pth) that exploit the weights_only unpickler. This flaw leads to memory corruption when loading such files with torch.load(..., weights_only=True). The issue is fixed in PyTorch 2.10.0.
A vulnerability in PHP versions 8.1 before 8.1.33, 8.2 before 8.2.29, 8.3 before 8.3.23, and 8.4 before 8.4.10 allows null byte characters in hostnames passed to functions like fsockopen(). This can cause inconsistent hostname parsing by other functions such as parse_url(), potentially leading to security issues if user code relies on these functions for access control. Red Hat has issued security updates addressing this issue.
A vulnerability in Node.js TLS error handling allows remote attackers to crash or exhaust resources of a TLS server when using pskCallback or ALPNCallback. Synchronous exceptions thrown during these callbacks bypass normal TLS error handling, causing process termination or resource leaks leading to denial of service. This affects multiple Node.js versions where these callbacks are not safely wrapped.
A critical flaw in Node.js version 25's permission model allows Unix Domain Socket (UDS) connections to bypass network restrictions when the --permission flag is enabled. This vulnerability permits attacker-controlled inputs to connect to arbitrary local sockets even without the --allow-net permission, breaking the intended security boundary. This can lead to privilege escalation, data exposure, or local code execution. The issue affects Node.js versions from 25.0.0 up to but not including 25.3.0. A patch is available for this vulnerability.
A memory leak vulnerability exists in Node.js's OpenSSL integration when converting X.509 certificate fields to UTF-8. This occurs because the allocated buffer is not freed during the conversion process. Remote clients can exploit this by repeatedly establishing TLS connections that call socket.getPeerCertificate(true), causing steady memory growth. Over time, this can lead to resource exhaustion and denial of service. The issue affects Node.js versions from 24.0.0 up to but not including 24.12.0. A fix is available in version 24.12.0.
A vulnerability in Node.js's permission model allows modification of a file's access and modification timestamps via the futimes() function even when the process only has read permissions. This occurs because futimes() does not enforce the expected write-permission checks, unlike utimes(). This flaw affects Node.js versions 20.0.0 up to but not including 20.20.0, 21.0.0 up to but not including 22.22.0, 23.0.0 up to but not including 24.13.0, and 25.0.0 up to but not including 25.3.0. The vulnerability could be used to obscure file activity by altering timestamps, impacting the reliability of logs. A patch is available to address this issue.
A heap buffer overflow vulnerability exists in the PHP array_merge() function in versions prior to 8.1.34, 8.2.30, 8.3.29, 8.4.16, and 8.5.1. The flaw occurs due to an integer overflow in element count precomputation when merging packed arrays with a total element count exceeding 32-bit limits or HT_MAX_SIZE. This can lead to memory corruption or crashes, affecting server integrity and availability. Red Hat has released security updates addressing this issue in their PHP packages for Red Hat Enterprise Linux 9.6 Extended Update Support.
A flaw was found in Moodle. An attacker with access to the restore interface could trigger server-side execution of arbitrary code. This is due to insufficient validation of restore input, which leads to unintended interpretation by core restore routines. Successful exploitation could result in a full compromise of the Moodle application.
The "create core" API of Apache Solr 8.6 through 9.10.0 lacks sufficient input validation on some API parameters, which can cause Solr to check the existence of and attempt to read file-system paths that should be disallowed by Solr's "allowPaths" security setting https://https://solr.apache.org/guide/solr/latest/configuration-guide/configuring-solr-xml.html#the-solr-element . These read-only accesses can allow users to create cores using unexpected configsets if any are accessible via the filesystem. On Windows systems configured to allow UNC paths this can additionally cause disclosure of NTLM "user" hashes.
Solr deployments are subject to this vulnerability if they meet the following criteria:
* Solr is running in its "standalone" mode.
* Solr's "allowPath" setting is being used to restrict file access to certain directories.
* Solr's "create core" API is exposed and accessible to untrusted users. This can happen if Solr's RuleBasedAuthorizationPlugin https://solr.apache.org/guide/solr/latest/deployment-guide/rule-based-authorization-plugin.html is disabled, or if it is enabled but the "core-admin-edit" predefined permission (or an equivalent custom permission) is given to low-trust (i.e. non-admin) user roles.
Users can mitigate this by enabling Solr's RuleBasedAuthorizationPlugin (if disabled) and configuring a permission-list that prevents untrusted users from creating new Solr cores. Users should also upgrade to Apache Solr 9.10.1 or greater, which contain fixes for this issue.
Deployments of Apache Solr 5.3.0 through 9.10.0 that rely on Solr's "Rule Based Authorization Plugin" are vulnerable to allowing unauthorized access to certain Solr APIs, due to insufficiently strict input validation in those components. Only deployments that meet all of the following criteria are impacted by this vulnerability:
* Use of Solr's "RuleBasedAuthorizationPlugin"
* A RuleBasedAuthorizationPlugin config (see security.json) that specifies multiple "roles"
* A RuleBasedAuthorizationPlugin permission list (see security.json) that uses one or more of the following pre-defined permission rules: "config-read", "config-edit", "schema-read", "metrics-read", or "security-read".
* A RuleBasedAuthorizationPlugin permission list that doesn't define the "all" pre-defined permission
* A networking setup that allows clients to make unfiltered network requests to Solr. (i.e. user-submitted HTTP/HTTPS requests reach Solr as-is, unmodified or restricted by any intervening proxy or gateway)
Users can mitigate this vulnerability by ensuring that their RuleBasedAuthorizationPlugin configuration specifies the "all" pre-defined permission and associates the permission with an "admin" or other privileged role. Users can also upgrade to a Solr version outside of the impacted range, such as the recently released Solr 9.10.1.
We have identified a bug in Node.js error handling where "Maximum call stack size exceeded" errors become uncatchable when `async_hooks.createHook()` is enabled. Instead of reaching `process.on('uncaughtException')`, the process terminates, making the crash unrecoverable. Applications that rely on `AsyncLocalStorage` (v22, v20) or `async_hooks.createHook()` (v24, v22, v20) become vulnerable to denial-of-service crashes triggered by deep recursion under specific conditions.
A malformed `HTTP/2 HEADERS` frame with oversized, invalid `HPACK` data can cause Node.js to crash by triggering an unhandled `TLSSocket` error `ECONNRESET`. Instead of safely closing the connection, the process crashes, enabling a remote denial of service. This primarily affects applications that do not attach explicit error handlers to secure sockets, for example:
```
server.on('secureConnection', socket => {
socket.on('error', err => {
console.log(err)
})
})
```
GitLab CE/EE versions from 15.10 up to but not including 18.3.6, 18.4 up to but not including 18.4.4, and 18.5 up to but not including 18.5.2 contain a stored cross-site scripting (XSS) vulnerability in the Kubernetes proxy functionality. This vulnerability allows an authenticated user to execute malicious scripts due to improper input validation during web page generation. The issue has been remediated in versions 18.3.6, 18.4.4, and 18.5.2 and later.
A stored cross-site scripting (XSS) vulnerability exists in GitLab CE/EE versions from 18.2.2 before 18.5.5, 18.6 before 18.6.3, and 18.7 before 18.7.1. An authenticated user could exploit GitLab Flavored Markdown to inject malicious scripts that execute in other users' browsers. This vulnerability has been remediated by GitLab.
A missing authorization vulnerability in GitLab EE versions 18.4 before 18.5.5, 18.6 before 18.6.3, and 18.7 before 18.7.1 allows authenticated users to access and manipulate AI model settings from unauthorized namespaces by tampering with namespace identifiers in API requests. This leads to unauthorized information disclosure and potential misuse of AI resources. A patch is available to remediate this issue.
A critical cross-site scripting (XSS) vulnerability exists in GitLab Community and Enterprise Editions affecting versions from 18.6 up to but not including 18.6.3, and 18.7 up to but not including 18.7.1. This vulnerability could allow an unauthenticated attacker to execute arbitrary code in the context of an authenticated user's browser by tricking the user into visiting a specially crafted webpage. GitLab has remediated this issue in versions 18.6.3 and 18.7.1.
Cosign provides code signing and transparency for containers and binaries. Prior to versions 2.6.2 and 3.0.4, Cosign bundle can be crafted to successfully verify an artifact even if the embedded Rekor entry does not reference the artifact's digest, signature or public key. When verifying a Rekor entry, Cosign verifies the Rekor entry signature, and also compares the artifact's digest, the user's public key from either a Fulcio certificate or provided by the user, and the artifact signature to the Rekor entry contents. Without these comparisons, Cosign would accept any response from Rekor as valid. A malicious actor that has compromised a user's identity or signing key could construct a valid Cosign bundle by including any arbitrary Rekor entry, thus preventing the user from being able to audit the signing event. This issue has been patched in versions 2.6.2 and 3.0.4.
virtualenv is a tool for creating isolated virtual python environments. Prior to version 20.36.1, TOCTOU (Time-of-Check-Time-of-Use) vulnerabilities in virtualenv allow local attackers to perform symlink-based attacks on directory creation operations. An attacker with local access can exploit a race condition between directory existence checks and creation to redirect virtualenv's app_data and lock file operations to attacker-controlled locations. This issue has been patched in version 20.36.1.