ghsa

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.

### Summary The ChecksumCalculator class within allows for hashing and checksum generation, but it includes or defaults to algorithms that are no longer recommended for secure cryptographic use cases (e.g., SHA-1, CRC32, and SSDEEP). These algorithms, while possibly valid for certain non-security-critical tasks, can expose users to security risks if used in scenarios where strong cryptographic guarantees are required. ### Requirement from NIST Requirement from NIST regarding SHA1 https://csrc.nist.gov/projects/hash-functions#:~:text=NIST%20deprecated%20the%20use%20of,use%20of%20the%20SHA%2D1. > Federal agencies should use SHA-2 or SHA-3 as an alternative to SHA-1. > Further guidance will be available soon. Send questions on the transition to sha-1-transition@nist.gov. https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm ### Mitigation and Fix Make it clear to developers and users that the ChecksumCalculator is specific to the "Known File Filter...

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.