ghsa

### Impact In all Envoy Gateway versions prior to 1.2.7 and 1.3.1 a default Envoy Proxy access log configuration is used. This format is vulnerable to log injection attacks. If the attacker uses a specially crafted user-agent which performs json injection, then he could add and overwrite fields to the access log. Examples of attacks include: - Using following string as user agent : `HELLO-WORLD", "evil-ip": "1.1.1.1", "x-forwarded-for": "1.1.1.1` would lead to setting of new access log properties and overwrite of existing properties. Existing properties such as the value of the X-Forwarded-For header may have importance for security analysis of access logs, and their overwrite can be used to hide malicious activity. - Using the following string as user-agent : `"` which renders an invalid json document. The invalid document may fail to be processed by observability solutions, which would allow attacker to hide malicious activity. ### Patches 1.3.1, 1.2.7 ### Fix Using JSON ...

### Summary The API endpoint related to the password reset function is vulnerable to Reflected Cross-Site-Scripting. ### Details Throughout the source-code analysis, it has been found that the endpoint /api/v1/db/auth/password/reset/:tokenId is vulnerable to Reflected Cross-Site-Scripting. The flaw occurs due to implementation of the client-side template engine ejs, specifically on file resetPassword.ts where the template is using the insecure function “<%-“ https://github.com/nocodb/nocodb/blob/ba5a191b33259d984fc92df225f7d82ede2ddb56/packages/nocodb/src/modules/auth/ui/auth/resetPassword.ts#L71 which is rendered by the function renderPasswordReset: https://github.com/nocodb/nocodb/blob/ba5a191b33259d984fc92df225f7d82ede2ddb56/packages/nocodb/src/modules/auth/auth.controller.ts#L251 ### PoC Send the request below to a vulnerable instance: `/api/v1/db/auth/password/reset/asdsad%3C%2F%73%63%72%69%70%74%3E%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%31%29%3C%2F%73%63%72%69%70%...

Versions of the package ray before 2.43.0 are vulnerable to Insertion of Sensitive Information into Log File where the redis password is being logged in the standard logging. If the redis password is passed as an argument, it will be logged and could potentially leak the password. This is only exploitable if: 1) Logging is enabled; 2) Redis is using password authentication; 3) Those logs are accessible to an attacker, who can reach that redis instance. **Note:** It is recommended that anyone who is running in this configuration should update to the latest version of Ray, then rotate their redis password.

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 [email protected]. 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.