VAITP

lxml_html_clean is a project for HTML cleaning functionalities copied from `lxml.html.clean`. Prior to version 0.4.0, 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. Users employing the HTML cleaner in a security-sensitive context should upgrade to lxml 0.4.0, which addresses this issue. As a temporary mitigation, users can configure lxml_html_clean with the following settings to prevent the exploitation of this vulnerability. Via `remove_tags`, one may specify tags to remove - their content is moved to their parents' tags. Via `kill_tags`, one may specify tags to be removed completely. Via `allow_tags`, one may restrict the set of permissible tags, excluding context-switching tags like `<svg>`, `<math>` and `<noscript>`.

The user avatar upload function in python_book V1.0 has an arbitrary file upload vulnerability.

The python_food ordering system V1.0 has an unauthorized vulnerability that leads to the leakage of sensitive user information. Attackers can access it through https://ip:port/api/myapp/index/user/info?id=1 And modify the ID value to obtain sensitive user information beyond authorization.

python_book V1.0 is vulnerable to Incorrect Access Control, which allows attackers to obtain sensitive information of users with different IDs by modifying the ID parameter.

A Python command injection vulnerability exists in the `SagemakerLLM` class's `complete()` method within `./private_gpt/components/llm/custom/sagemaker.py` of the imartinez/privategpt application, versions up to and including 0.3.0. The vulnerability arises due to the use of the `eval()` function to parse a string received from a remote AWS SageMaker LLM endpoint into a dictionary. This method of parsing is unsafe as it can execute arbitrary Python code contained within the response. An attacker can exploit this vulnerability by manipulating the response from the AWS SageMaker LLM endpoint to include malicious Python code, leading to potential execution of arbitrary commands on the system hosting the application. The issue is fixed in version 0.6.0.

A flaw was found in OpenStack. When a user tries to delete a non-existing access rule in it's scope, it deletes other existing access rules which are not associated with any application credentials.

Rejected reason: Various versions of Python do not properly restrict readline calls, which allows remote attackers to cause a denial of service (memory consumption) via a long string, related to (1) httplib - fixed in 2.7.4, 2.6.9, and 3.3.3; (2) ftplib - fixed in 2.7.6, 2.6.9, 3.3.3; (3) imaplib - not yet fixed in 2.7.x, fixed in 2.6.9, 3.3.3; (4) nntplib - fixed in 2.7.6, 2.6.9, 3.3.3; (5) poplib - not yet fixed in 2.7.x, fixed in 2.6.9, 3.3.3; and (6) smtplib - not yet fixed in 2.7.x, fixed in 2.6.9, not yet fixed in 3.3.x. NOTE: this was REJECTed because it is incompatible with CNT1 "Independently Fixable" in the CVE Counting Decisions

An issue in pyload-ng v0.5.0b3.dev85 running under python3.11 or below allows attackers to execute arbitrary code via a crafted HTTP request.

langflow v1.0.12 was discovered to contain a remote code execution (RCE) vulnerability via the PythonCodeTool component.

<p>Depending on configuration of various package managers it is possible for an attacker to insert a malicious package into a package manager's repository which can be retrieved and used during development, build, and release processes. This insertion could lead to remote code execution. We believe this vulnerability affects multiple package managers across multiple languages, including but not limited to: Python/pip, .NET/NuGet, Java/Maven, JavaScript/npm.</p> <p><strong>Attack scenarios</strong></p> <p>An attacker could take advantage of this ecosystem-wide issue to cause harm in a variety of ways. The original attack scenarios were discovered by Alex Birsan and are detailed in their whitepaper, <a href="https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610">Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies</a>.</p> <ul> <li><p>With basic knowledge of the target ecosystems, an attacker could create an empty shell for a package and insert malicious code in the install scripts, give it a high version, and publish it to the public repository. Vulnerable victim machines will download the higher version of the package between the public and private repositories and attempt to install it. Due to code incompatibility it will probably error out upon import or upon compilation, making it easier to detect; however the attacker would have gained code execution by that point.</p> </li> <li><p>An advanced attacker with some inside knowledge of the target could take a copy of a working package, insert the malicious code (in the package itself or in the install), and then publish it to a public repository. The package will likely install and import correctly, granting the attacker an initial foothold and persistence.</p> </li> </ul> <p>These two methods could affect target organizations at any of these various levels:</p> <ul> <li>Developer machines</li> <li>An entire team if the configuration to import the malicious package is uploaded to a code repository</li> <li>Continuous integration pipelines if they pull the malicious packages during the build, test, and/or deploy stages</li> <li>Customers, download servers, production services if the malicious code has not been detected</li> </ul> <p>This remote code execution vulnerability can only be addressed by reconfiguring installation tools and workflows, and not by correcting anything in the package repositories themselves. See the <strong>FAQ</strong> section of this CVE for configuration guidance.</p>