ghsa

An issue was discovered in Django 5.1 before 5.1.7, 5.0 before 5.0.13, and 4.2 before 4.2.20. The django.utils.text.wrap() method and wordwrap template filter are subject to a potential denial-of-service attack when used with very long strings.

### Impact In vulnerable versions of Fleet, an attacker could craft a specially-formed SAML response to: - Forge authentication assertions, potentially impersonating legitimate users. - If Just-In-Time (JIT) provisioning is enabled, the attacker could provision a new administrative user account. - If MDM enrollment is enabled, certain endpoints could be used to create new accounts tied to forged assertions. This could allow unauthorized access to Fleet, including administrative access, visibility into device data, and modification of configuration. ### Patches This issue is addressed in commit [fc96cc4](https://github.com/fleetdm/fleet/commit/fc96cc4e91047250afb12f65ad70e90b30a7fb1c) and is available in Fleet version 4.64.2. The following backport versions also address this issue: - 4.63.2 - 4.62.4 - 4.58.1 ### Workarounds If an immediate upgrade is not possible, Fleet users should temporarily disable [single-sign-on (SSO)](https://fleetdm.com/docs/deploy/single-sign-on-sso)...

### 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 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...