#vulnerability

**What privileges could be gained by an attacker who successfully exploited this vulnerability?** An attacker who successfully exploited this vulnerability could gain Kernel Memory Access.

**What privileges could be gained by an attacker who successfully exploited this vulnerability?** An attacker who successfully exploited this vulnerability could gain SYSTEM privileges.

**What privileges could be gained by an attacker who successfully exploited this vulnerability?** An attacker who successfully exploited this vulnerability could gain SYSTEM privileges.

**According to the CVSS metric, the attack complexity is high (AC:H). What does that mean for this vulnerability?** Successful exploitation of this vulnerability requires an attacker to win a race condition.

Taiwanese company Moxa has released a security update to address a critical security flaw impacting its PT switches that could permit an attacker to bypass authentication guarantees. The vulnerability, tracked as CVE-2024-12297, has been assigned a CVSS v4 score of 9.2 out of a maximum of 10.0. "Multiple Moxa PT switches are vulnerable to an authentication bypass because of flaws in their

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Monday added five security flaws impacting Advantive VeraCore and Ivanti Endpoint Manager (EPM) to its Known Exploited Vulnerabilities (KEV) catalog, based on evidence of active exploitation in the wild. The list of vulnerabilities is as follows - CVE-2024-57968 - An unrestricted file upload vulnerability in Advantive VeraCore

### Impact Users with an enabled repository with access to repo level CI secrets in Vela are vulnerable to the exploit. Any user with access to the CI instance and the linked source control manager can perform the exploit. ### Method By spoofing a webhook payload with a specific set of headers and body data, an attacker could transfer ownership of a repository and its repo level secrets to a separate repository. These secrets could be exfiltrated by follow up builds to the repository. ### Patches `v0.26.3` — Image: `target/vela-server:v0.26.3` `v0.25.3` — Image: `target/vela-server:v0.25.3` ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ There are no workarounds to the issue. ### References _Are there any links users can visit to find out more?_ Please see linked CWEs (common weakness enumerators) for more information.

## Summary `Rack::Static` can serve files under the specified `root:` even if `urls:` are provided, which may expose other files under the specified `root:` unexpectedly. ## Details The vulnerability occurs because `Rack::Static` does not properly sanitize user-supplied paths before serving files. Specifically, encoded path traversal sequences are not correctly validated, allowing attackers to access files outside the designated static file directory. ## Impact By exploiting this vulnerability, an attacker can gain access to all files under the specified `root:` directory, provided they are able to determine then path of the file. ## Mitigation - Update to the latest version of Rack, or - Remove usage of `Rack::Static`, or - Ensure that `root:` points at a directory path which only contains files which should be accessed publicly. It is likely that a CDN or similar static file server would also mitigate the issue.

Concrete CMS versions 9.0.0 through 9.3.9 are affected by a stored XSS in Folder Function.The "Add Folder" functionality lacks input sanitization, allowing a rogue admin to inject XSS payloads as folder names.  The Concrete CMS security team gave this vulnerability a CVSS 4.0 Score of 4.8 with vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:P/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N. Versions below 9 are not affected. Thanks, Alfin Joseph for reporting.

This vulnerability is caused by the improper mapping of users to organizations based solely on email/username patterns. The issue is limited to the token claim level, meaning the user is not truly added to the organization but may appear as such in applications relying on these claims. The risk increases in scenarios where self-registration is enabled and unrestricted, allowing an attacker to exploit the naming pattern. The issue is mitigated if admins restrict registration or use strict validation mechanisms.