Source
ghsa
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in django CMS Association django CMS Attributes Fields allows Stored XSS.This issue affects django CMS Attributes Fields: before 4.0.
### Impact The HTML Parser in lxml does not properly handle context-switching for special HTML tags such as `<svg>`, `<math>` and `<noscript>`. This behavior deviates from how web browsers parse and interpret such tags. Specifically, content in CSS comments is ignored by lxml_html_clean but may be interpreted differently by web browsers, enabling malicious scripts to bypass the cleaning process. This vulnerability could lead to Cross-Site Scripting (XSS) attacks, compromising the security of users relying on lxml_html_clean in default configuration for sanitizing untrusted HTML content. ### Patches Users employing the HTML cleaner in a security-sensitive context should upgrade to lxml 0.4.0, which addresses this issue. ### Workarounds As a temporary mitigation, users can configure lxml_html_clean with the following settings to prevent the exploitation of this vulnerability: * `remove_tags`: Specify tags to remove - their content is moved to their parents' tags. * `kill_tags`: Spec...
### **tl;dr:** unprivileged user creates a symlink to /etc/sudoers, /etc/shadow or similar and waits for a privileged user or process to copy/backup/mirror users data (using `--links` and `--metadata`). unprivileged user now owns /etc/sudoers. ### Summary Insecure handling of symlinks with `--links` and `--metadata` in rclone while copying to local disk allows unprivileged users to indirectly modify ownership and permissions on symlink target files when a superuser or privileged process performs a copy. This vulnerability could enable privilege escalation and unauthorized access to critical system files (e.g., /etc/shadow), compromising system integrity, confidentiality, and availability. For instance, an unprivileged user could set a symlink to a sensitive file within their home directory, waiting for an administrator or automated process (e.g., a cron job running with elevated privileges) to copy their files with rclone using the --links and --metadata options. Upon copying, rclo...
The mediapool feature of the Redaxo Core CMS application v 5.17.1 is vulnerable to Cross Site Scripting(XSS) which allows a remote attacker to escalate privileges.
Assets uploaded with appropriately crafted filenames may result in them being placed in a location different than what was configured. ### Impact - Affects front-end forms with `assets` fields. - Affects other places where assets can be uploaded, although users would need upload permissions anyway. - Files can be uploaded so they would be located on the server in a different location, and potentially override existing files. - Traversal _outside_ an asset container was not possible. ### Patches This has been fixed in 5.17.0.
Files or Directories Accessible to External Parties, Improper Privilege Management vulnerability in Apache Kafka Clients. Apache Kafka Clients accept configuration data for customizing behavior, and includes ConfigProvider plugins in order to manipulate these configurations. Apache Kafka also provides FileConfigProvider, DirectoryConfigProvider, and EnvVarConfigProvider implementations which include the ability to read from disk or environment variables. In applications where Apache Kafka Clients configurations can be specified by an untrusted party, attackers may use these ConfigProviders to read arbitrary contents of the disk and environment variables. In particular, this flaw may be used in Apache Kafka Connect to escalate from REST API access to filesystem/environment access, which may be undesirable in certain environments, including SaaS products. This issue affects Apache Kafka Clients: from 2.3.0 through 3.5.2, 3.6.2, 3.7.0. Users with affected applications are recommended ...
### Summary Versions of step-security/harden-runner prior to v2.10.2 contain multiple command injection weaknesses via environment variables that could potentially be exploited under specific conditions. However, due to the current execution order of pre-steps in GitHub Actions and the placement of harden-runner as the first step in a job, the likelihood of exploitation is low as the Harden-Runner action reads the environment variable during the pre-step stage. There are no known exploits at this time. ### Details 1. setup.ts:169 [1] performs `execSync` with a command that gets invoked after interpretation by the shell. This command includes an interpolated `process.env.USER` variable, which an attacker could modify (without actually creating a new user) to inject arbitrary shell expressions into this `execSync`. This may or may not be likely in practice, but I believe the hygienic way to perform the underlying operation is to use `execFileSync` or similar and bypass the underlyin...
### Summary The Python parser parses newlines in chunk extensions incorrectly which can lead to request smuggling vulnerabilities under certain conditions. ### Impact If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or `AIOHTTP_NO_EXTENSIONS` is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections. ----- Patch: https://github.com/aio-libs/aiohttp/commit/259edc369075de63e6f3a4eaade058c62af0df71
### Summary A memory leak can occur when a request produces a `MatchInfoError`. This was caused by adding an entry to a cache on each request, due to the building of each `MatchInfoError` producing a unique cache entry. ### Impact If the user is making use of any middlewares with `aiohttp.web` then it is advisable to upgrade immediately. An attacker may be able to exhaust the memory resources of a server by sending a substantial number (100,000s to millions) of such requests. ----- Patch: https://github.com/aio-libs/aiohttp/commit/bc15db61615079d1b6327ba42c682f758fa96936
Affected versions of this crate allowed for a bias when generating random polynomials for Shamir Secret Sharing, where instead of being within the range `[0, 255]` they were instead in the range `[1, 255]`. A description from Cure53, who originally found the issue, is available: > The correct method to select a random polynomial would be to select all coefficients (including the most significant coefficient) uniformly in the range 0..255 (inclusive). Otherwise, knowledge that a coefficient in a polynomial cannot be 0 permits the exclusion of single byte values for the shared secret given one share less than required. [...] Exploiting this weakness necessitates sharing the same secret multiple times. In this scenario, an attacker could exclude an exponential number of values for each of the shared bytes until sufficiently few values remain for brute forcing. Cure53 estimates that under ideal circumstances (e.g., a 2-out-of-N scheme) a shared secret can be reconstructed if the same sec...