ghsa

### Summary Enabled but unsecured management endpoints are susceptible to drive-by localhost attacks. While not typical of a production application, these attacks may have more impact on a development environment where such endpoints may be flipped on without much thought. ### Details A malicious/compromised website can make HTTP requests to `localhost`. Normally, such requests would trigger a CORS preflight check which would prevent the request; however, some requests are ["simple"](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests) and do not require a preflight check. These endpoints, if enabled and not secured, are vulnerable to being triggered. ### Impact Production environments typically disable unused endpoints and secure/restrict access to needed endpoints. A more likely victim is the developer in their local development host, who has enabled endpoints without security for the sake of easing development.

### Impact This security advisory pertains to a potential information leak (e.g., environment variables) in instances where developers utilize `MessageTemplate` and incorporate user-provided data into templates. ### Patches The identified vulnerability has been remedied in fix #2509 and will be included in versions released after 2.1.3. Users are strongly advised to upgrade to these patched versions to safeguard against the vulnerability. ### Workarounds A temporary workaround involves filtering underscores before incorporating user input into the message template. ### References - [Pull Request #2509](https://github.com/nonebot/nonebot2/pull/2509) - [CWE-1336](https://cwe.mitre.org/data/definitions/1336.html)

HashiCorp Nomad and Nomad Enterprise 1.5.13 up to 1.6.6, and 1.7.3 template renderer is vulnerable to arbitrary file write on the host as the Nomad client user through symlink attacks. Fixed in Nomad 1.7.4, 1.6.7, 1.5.14.

### Summary In `eza`, there exists a potential heap overflow vulnerability, first seen when using Ubuntu for Raspberry Pi series system, on `ubuntu-raspi` kernel, relating to the `.git` directory. ### Details The vulnerability seems to be triggered by the `.git` directory in some projects. This issue may be related to specific files, and the directory structure also plays a role in triggering the vulnerability. Files/folders that may be involved in triggering the vulnerability include `.git/HEAD`, `.git/refs`, and `.git/objects`. As @polly pointed out to me, this is likely caused by [GHSA-j2v7-4f6v-gpg8](https://github.com/libgit2/libgit2/security/advisories/GHSA-j2v7-4f6v-gpg8), which we do seem to use currently. ### PoC For more information check @CuB3y0nd's blogpost [blog](https://www.cubeyond.net/blog/eza-cve-report). ### Impact Arbitrary code execution.

### Impact A vulnerability has been identified in which unauthenticated cross-site scripting (XSS) in the API Server's public API endpoint can be exploited. This can lead to an attacker exploiting the vulnerability to trigger JavaScript code and execute commands remotely. The attack vector was identified as a Reflected XSS. API Server propagates malicious payloads from user input to the UI, which renders the output. For example, a malicious URL gets rendered into a script that is executed on a page. The changes addressed by this fix are: - Encode input that comes from the request URL before adding it to the response. - The request input is escaped by changing the URL construction that is used for links to use `url.URL`. - The request input is escaped by escaping the JavaScript and CSS variables with attribute encoding as defined by [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#output-encoding-rules-summary). ### Patches Pat...

### Impact A vulnerability has been identified in which unauthenticated cross-site scripting (XSS) in Norman's public API endpoint can be exploited. This can lead to an attacker exploiting the vulnerability to trigger JavaScript code and execute commands remotely. The attack vector was identified as a Reflected XSS. Norman API propagates malicious payloads from user input to the UI, which renders the output. For example, a malicious URL gets rendered into a script that is executed on a page. The changes addressed by this fix are: - Encode input that comes from the request URL before adding it to the response. - The request input is escaped by changing the URL construction that is used for links to use `url.URL`. - The request input is escaped by escaping the JavaScript and CSS variables with attribute encoding as defined by [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#output-encoding-rules-summary). ### Patches Patched ver...

### Impact A vulnerability has been identified which may lead to sensitive data being leaked into Rancher's audit logs. [Rancher Audit Logging](https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-api-audit-log) is an opt-in feature, only deployments that have it enabled and have [AUDIT_LEVEL](https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-api-audit-log#audit-log-levels) set to `1 or above` are impacted by this issue. The leaks might be caught in the audit logs upon these actions: - Creating cloud credentials or new authentication providers. It is crucial to note that **all** [authentication providers](https://ranchermanager.docs.rancher.com/pages-for-subheaders/authentication-config#external-vs-local-authentication) (such as AzureAD) and [cloud providers](https://ranchermanager.docs.rancher.com/pages-for-subheaders/set-up-cloud-providers) (such as Google) are impacted. - Downloading a kubeconfig file from a downstream...

### Impact A vulnerability has been identified when granting a `create` or `*` **global role** for a resource type of "namespaces"; no matter the API group, the subject will receive `*` permissions for core namespaces. This can lead to someone being capable of accessing, creating, updating, or deleting a namespace in the project. This includes reading or updating a namespace in the project so that it is available in other projects in which the user has the "manage-namespaces" permission or updating another namespace in which the user has normal "update" permissions to be moved into the project. The expected behavior is to not be able to create, update, or delete a namespace in the project or move another namespace into the project since the user doesn't have any permissions on namespaces in the core API group. Moving a namespace to another project could lead to leakage of secrets, in case the targeted project has secrets. And also can lead to the namespace being able to abuse the res...

### Impact The attachment file of an existing record can be replaced if the user has `"read"` permission on one of the parent (collection or bucket). And if the `"read"` permission is given to `"system.Everyone"` on one of the parent, then the attachment can be replaced on a record using an anonymous request. Note that if the parent has no explicit read permission, then the records attachments are safe. ### Patches - Patch released in kinto-attachment 6.4.0 - https://github.com/Kinto/kinto-attachment/commit/f4a31484f5925cbc02b59ebd37554538ab826ca1 ### Workarounds None if the read permission has to remain granted. Updating to 6.4.0 or applying the patch individually (if updating is not feasible) is strongly recommended. ### References - https://bugzilla.mozilla.org/show_bug.cgi?id=1879034

An issue in NPM IP Package v.1.1.8 and before allows an attacker to execute arbitrary code and obtain sensitive information via the `isPublic()` function. This can lead to potential Server-Side Request Forgery (SSRF) attacks. The core issue is the function's failure to accurately distinguish between public and private IP addresses.