#vulnerability

Jenkins 2.499 and earlier, LTS 2.492.1 and earlier does not require POST requests for the HTTP endpoint toggling collapsed/expanded status of sidepanel widgets (e.g., Build Queue and Build Executor Status widgets), resulting in a cross-site request forgery (CSRF) vulnerability. This vulnerability allows attackers to have users toggle their collapsed/expanded status of sidepanel widgets. Additionally, as the API accepts any string as the identifier of the panel ID to be toggled, attacker-controlled content can be stored in the victim’s user profile in Jenkins. Jenkins 2.500, LTS 2.492.2 requires POST requests for the affected HTTP endpoint.

Various features in Jenkins redirect users to partially user-controlled URLs inside Jenkins. To prevent open redirect vulnerabilities, Jenkins limits redirections to safe URLs (neither absolute nor scheme-relative/network-path reference). In Jenkins 2.499 and earlier, LTS 2.492.1 and earlier, redirects starting with backslash (`\`) characters are considered safe. This allows attackers to perform phishing attacks by having users go to a Jenkins URL that will forward them to a different site, because browsers interpret these characters as part of scheme-relative redirects. Jenkins 2.500, LTS 2.492.2 considers redirects to URLs starting with backslash (`\`) characters to be unsafe, rejecting such redirects.

Jenkins 2.499 and earlier, LTS 2.492.1 and earlier does not redact encrypted values of secrets when accessing `config.xml` of agents via REST API or CLI. This allows attackers with Agent/Extended Read permission to view encrypted values of secrets. Jenkins 2.500, LTS 2.492.2 redacts the encrypted values of secrets stored in agent `config.xml` accessed via REST API or CLI for users lacking Agent/Configure permission.

Jenkins 2.499 and earlier, LTS 2.492.1 and earlier does not redact encrypted values of secrets when accessing `config.xml` of views via REST API or CLI. This allows attackers with View/Read permission to view encrypted values of secrets. Jenkins 2.500, LTS 2.492.2 redacts the encrypted values of secrets stored in view `config.xml` accessed via REST API or CLI for users lacking View/Configure permission.

A Server-Side Template Injection (SSTI) vulnerability in Spacy-LLM v0.7.2 allows attackers to execute arbitrary code via injecting a crafted payload into the template field.

An oversight in how the Jinja sandboxed environment interacts with the `|attr` filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to `str.format` and ensures they don't escape the sandbox. However, it's possible to use the `|attr` filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the `|attr` filter no longer bypasses the environment's attribute lookup.

### Impact Dgl implements rpc server (start_server() in rpc_server.py) for supporting the RPC communications among different remote users over networks. It relies on pickle serialize and deserialize to pack and unpack network messages. The is a known risk in pickle deserialization functionality that can be used for remote code execution. ### Patches TBD. ### Workarounds When running DGL distributed training and inference (DistDGL) make sure you do not assign public IPs to any instance in the cluster. ### References Issue #7874 ### Reported by Pinji Chen ([cpj24@mails.tsinghua.edu.cn](mailto:cpj24@mails.tsinghua.edu.cn)) from NISL lab (https://netsec.ccert.edu.cn/about) at Tsinghua University

Malicious, user-crafted request payloads could potentially lead to remote code execution within Volt components.

When using wildcard validation to validate a given file or image field array (`files.*`), a user-crafted malicious request could potentially bypass the validation rules.

### Summary Reflected cross-site scripting (XSS) is a type of web vulnerability that occurs when a web application fails to properly sanitize user input, allowing an attacker to inject malicious code into the application's response to a user's request. When the user's browser receives the response, the malicious code is executed, potentially allowing the attacker to steal sensitive information or take control of the user's account. ### Details On the latest version of Redaxo, v5.18.2, the rex-api-result parameter is vulnerable to Reflected cross-site scripting (XSS) on the page of AddOns. ### PoC 1. Login Redaxo as administrative user. 2. Navigate to the URL: [http://localhost/redaxo/index.php?page=packages&rex-api-call=package&&rex-api-result={%22succeeded%22%3Atrue%2C%22message%22%3A%22%3Cimg%20src=x%20onerror=alert(document.domain);%3E%22}](http://localhost/redaxo/index.php?page=packages&rex-api-call=package&&rex-api-result=%7B%22succeeded%22%3Atrue%2C%22message%22%3A%22%3Cimg%20s...