ghsa

Jenkins Azure VM Agents Plugin 852.v8d35f0960a_43 and earlier does not perform permission checks in several HTTP endpoints. This allows attackers with Overall/Read permission to connect to an attacker-specified Azure Cloud server using attacker-specified credentials IDs obtained through another method. Additionally, these HTTP endpoints do not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability. Azure VM Agents Plugin 853.v4a_1a_dd947520 requires POST requests and the appropriate permissions for the affected HTTP endpoints.

An XML Deserialization vulnerability in glazedlists v1.11.0 allows an attacker to execute arbitrary code via the BeanXMLByteCoder.decode() parameter.

Pimcore prior to 10.3.3 is vulnerable to stored cross-site scripting at the `Title field` in `SEO & Settings` tab of `Document`.

### Impact It's possible to exploit well known parameters in XWiki URLs to perform redirection to untrusted site. This vulnerability was partially fixed in the past for XWiki 12.10.7 and 13.3RC1 but there is still the possibility to force specific URLs to skip some checks, e.g. using URLs like `http:example.com` in the parameter would allow the redirect. ### Patches The issue has now been patched against all patterns that we know about for performing redirect. It also performs a real URI parsing that should protect in most cases. This has been patched in XWiki 14.10.4 and 15.0. ### Workarounds The only workaround is to upgrade XWiki. ### References * JIRA ticket: https://jira.xwiki.org/browse/XWIKI-20096 * JIRA ticket about the improvment actually fixing the vulnerability: https://jira.xwiki.org/browse/XWIKI-20549 * Previous advisory about open redirect: https://github.com/advisories/GHSA-jp55-vvmf-63mv ### For more information If you have any questions or comments abo...

A sandbox escape vulnerability exists in vm2 for versions up to 3.9.17. It abuses an unexpected creation of a host object based on the specification of `Proxy`. ### Impact A threat actor can bypass the sandbox protections to gain remote code execution rights on the host running the sandbox. ### Patches This vulnerability was patched in the release of version `3.9.18` of `vm2`. ### Workarounds None. ### References PoC - https://gist.github.com/arkark/e9f5cf5782dec8321095be3e52acf5ac ### For more information If you have any questions or comments about this advisory: - Open an issue in [VM2](https://github.com/patriksimek/vm2) Thanks to @arkark (Takeshi Kaneko) of GMO Cybersecurity by Ierae, Inc. for disclosing this vulnerability.

### Summary Arbitrary file read when using include file syntax. ### Details By using the syntax `--8<--"/etc/passwd"` or `--8<--"/proc/self/environ"` the content of these files will be rendered in the generated documentation. Additionally, a path relative to a specified, allowed base path can also be used to render the content of a file outside the specified base paths: `--8<-- "../../../../etc/passwd"`. Within the Snippets extension, there exists a `base_path` option but the implementation is vulnerable to Directory Traversal. The vulnerable section exists in `get_snippet_path(self, path)` lines 155 to 174 in snippets.py. ``` base = "docs" path = "/etc/passwd" filename = os.path.join(base,path) # Filename is now /etc/passwd ``` ### PoC ```py import markdown payload = "--8<-- \"/etc/passwd\"" html = markdown.markdown(payload, extensions=['pymdownx.snippets']) print(html) ``` ### Impact Any readable file on the host where the plugin is executing may have its content exposed. ...

Improper input validation in the Apache Sling Commons JSON bundle allows an attacker to trigger unexpected errors by supplying specially-crafted input. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. The org.apache.sling.commons.json bundle has been deprecated as of March 2017 and should not be used anymore. Consumers are encouraged to consider the Apache Sling Commons Johnzon OSGi bundle provided by the Apache Sling project, but may of course use other JSON libraries.

giturlparse (aka git-url-parse) through 1.2.2, as used in Semgrep through 1.21.0, is vulnerable to ReDoS (Regular Expression Denial of Service) if parsing untrusted URLs. This might be relevant if Semgrep is analyzing an untrusted package (for example, to check whether it accesses any Git repository at an http:// URL), and that package's author placed a ReDoS attack payload in a URL used by the package.

### Impact The secret file stores the user's Planet API authentication information. It should only be accessible by the user, but its permissions allowed the user's group and non-group to read the file as well. ### Validation Check the permissions on the secret file with `ls -l ~/.planet.json` and ensure that they read as `-rw-------` ### Patches [d71415a8](https://github.com/planetlabs/planet-client-python/commit/d71415a83119c5e89d7b80d5f940d162376ee3b7) ### Workarounds Set the secret file permissions to only user read/write by hand: ``` chmod 600 ~/.planet.json ```

### Impact during codegen, the length word of a dynarray is written before the data, which can result in OOB array access in the case where the dynarray is on both the lhs and rhs of an assignment. here is a minimal example producing the issue: ```vyper a:DynArray[uint256,3] @external def test() -> DynArray[uint256,3]: self.a = [1,2,3] self.a = empty(DynArray[uint256,3]) self.a = [self.a[0],self.a[1],self.a[2]] return self.a # return [1,2,3] ``` and here is an example demonstrating the issue can cause data corruption across call frames: ```vyper @external def test() -> DynArray[uint256,3]: self.a() return self.b() # return [1,2,3] @internal def a(): a: uint256 = 0 b: uint256 = 1 c: uint256 = 2 d: uint256 = 3 @internal def b() -> DynArray[uint256,3]: a: DynArray[uint256,3] = empty(DynArray[uint256,3]) a = [a[0],a[1],a[2]] return a ``` examples involving append and pop: ```vyper @internal def foo(): c: DynArray[uint...