Security
Headlines
HeadlinesLatestCVEs

Tag

#git

GHSA-hcp2-x6j4-29j7: RustCrypto: Signatures has timing side-channel in ML-DSA decomposition

### Summary A timing side-channel was discovered in the Decompose algorithm which is used during ML-DSA signing to generate hints for the signature. ### Details The analysis was performed using a constant-time analyzer that examines compiled assembly code for instructions with data-dependent timing behavior. The analyzer flags: - **UDIV/SDIV instructions**: Hardware division instructions have early termination optimizations where execution time depends on operand values. The `decompose` function used a hardware division instruction to compute `r1.0 / TwoGamma2::U32`. This function is called during signing through `high_bits()` and `low_bits()`, which process values derived from secret key components: - `(&w - &cs2).low_bits()` where `cs2` is derived from secret key component `s2` - `Hint::new()` calls `high_bits()` on values derived from secret key component `t0` **Original Code**: ```rust fn decompose<TwoGamma2: Unsigned>(self) -> (Elem, Elem) { // ... let mut r1 = r_pl...

ghsa
#git
GHSA-3fm2-xfq7-7778: HAXcms Has Stored XSS Vulnerability that May Lead to Account Takeover

### Summary Stored XSS Leading to Account Takeover ### Details The Exploit Chain: 1.Upload: The attacker uploads an `.html` file containing a JavaScript payload. 2.Execution: A logged-in administrator is tricked into visiting the URL of this uploaded file. 3.Token Refresh: The JavaScript payload makes a `fetch` request to the `/system/api/refreshAccessToken` endpoint. Because the administrator is logged in, their browser automatically attaches the `haxcms_refresh_token` cookie to this request. 4.JWT Theft: The server validates the refresh token and responds with a new, valid JWT access token in the JSON response. 5.Exfiltration: The JavaScript captures this new JWT from the response and sends it to an attacker-controlled server. 6.Account Takeover: The attacker now possesses a valid administrator JWT and can take full control of the application. Vulnerability recurrence: <img width="1198" height="756" alt="image" src="https://github.com/user-attachments/assets/7062d542-702e-4cbe-849...

GHSA-whqx-f9j3-ch6m: Cosign verification accepts any valid Rekor entry under certain conditions

### Impact A Cosign bundle can be crafted to successfully verify an artifact even if the embedded Rekor entry does not reference the artifact's digest, signature or public key. When verifying a Rekor entry, Cosign verifies the Rekor entry signature, and also compares the artifact's digest, the user's public key from either a Fulcio certificate or provided by the user, and the artifact signature to the Rekor entry contents. Without these comparisons, Cosign would accept any response from Rekor as valid. A malicious actor that has compromised a user's identity or signing key could construct a valid Cosign bundle by including any arbitrary Rekor entry, thus preventing the user from being able to audit the signing event. This vulnerability only affects users that provide a trusted root via `--trusted-root` or when fetched automatically from a TUF repository, when no trusted key material is provided via `SIGSTORE_REKOR_PUBLIC_KEY`. When using the default flag values in Cosign v3 to sign a...

GHSA-gxp5-mv27-vjcj: Jervis's AES CBC Mode is Without Authentication

### Vulnerability https://github.com/samrocketman/jervis/blob/157d2b63ffa5c4bb1d8ee2254950fd2231de2b05/src/main/groovy/net/gleske/jervis/tools/SecurityIO.groovy#L682-L684 https://github.com/samrocketman/jervis/blob/157d2b63ffa5c4bb1d8ee2254950fd2231de2b05/src/main/groovy/net/gleske/jervis/tools/SecurityIO.groovy#L720-L722 `AES/CBC/PKCS5Padding` lacks authentication, making it vulnerable to padding oracle attacks and ciphertext manipulation. ### Impact Severity is considered low for internal uses of this library but if there's any consumer using these methods directly then this is considered critical. Unlikely to matter due to the design of how AES-256-CBC is used in conjunction with RSA and SHA-256 checksum within Jervis. Jervis uses RSA to encrypt AES keys and a SHA-256 checksum of the encrypted data in local-only storage inaccessible from the web. After asymmetric decryption and before symmetric decryption, a SHA-256 checksum is performed on the metadata and encrypted data. A...

GHSA-5pq9-5mpr-jj85: Jervis Has a JWT Algorithm Confusion Vulnerability

### Vulnerability https://github.com/samrocketman/jervis/blob/157d2b63ffa5c4bb1d8ee2254950fd2231de2b05/src/main/groovy/net/gleske/jervis/tools/SecurityIO.groovy#L244-L249 The code doesn't validate that the JWT header specifies `"alg":"RS256"`. ### Impact Depending on the broader system, this could allow JWT forgery. Internally this severity is low since JWT is only intended to interface with GitHub. External users should consider severity moderate. ### Patches Jervis patch will explicitly verify the algorithm in the header matches expectations and further verify the JWT structure. Upgrade to Jervis 2.2. ### Workarounds External users should consider using an alternate JWT library or upgrade. ### References - [RFC 7518: JSON Web Algorithms](https://datatracker.ietf.org/doc/html/rfc7518)

GHSA-c9q6-g3hr-8gww: Jervis Has Weak Random for Timing Attack Mitigation

### Vulnerability https://github.com/samrocketman/jervis/blob/157d2b63ffa5c4bb1d8ee2254950fd2231de2b05/src/main/groovy/net/gleske/jervis/tools/SecurityIO.groovy#L593-L594 Uses `java.util.Random()` which is not cryptographically secure. ### Impact If an attacker can predict the random delays, they may still be able to perform timing attacks. ### Patches Jervis will use `SecureRandom` for timing randomization. Upgrade to Jervis 2.2. ### Workarounds None ### References - [OWASP Cryptographic Failures](https://owasp.org/Top10/A02_2021-Cryptographic_Failures/)

GHSA-36h5-vrq6-pp34: Jervis's Salt for PBKDF2 derived from password

### Vulnerability https://github.com/samrocketman/jervis/blob/157d2b63ffa5c4bb1d8ee2254950fd2231de2b05/src/main/groovy/net/gleske/jervis/tools/SecurityIO.groovy#L869-L870 https://github.com/samrocketman/jervis/blob/157d2b63ffa5c4bb1d8ee2254950fd2231de2b05/src/main/groovy/net/gleske/jervis/tools/SecurityIO.groovy#L894-L895 The salt is derived from sha256Sum(passphrase). Two encryption operations with the same password will have the same derived key. ### Impact Pre-computation attacks. Severity is considered low for internal uses of this library and high for consumers of this library. ### Patches Jervis will generate a random salt for each password and store it alongside the ciphertext. Upgrade to Jervis 2.2. ### Workarounds None ### References - [NIST SP 800-132: Password-Based Key Derivation](https://csrc.nist.gov/publications/detail/sp/800-132/final)

GHSA-67rj-pjg6-pq59: Jervis Has a SHA-256 Hex String Padding Bug

### Vulnerability https://github.com/samrocketman/jervis/blob/157d2b63ffa5c4bb1d8ee2254950fd2231de2b05/src/main/groovy/net/gleske/jervis/tools/SecurityIO.groovy#L622-L626 `padLeft(32, '0')` should be `padLeft(64, '0')`. SHA-256 produces 32 bytes = 64 hex characters. ### Impact * Inconsistent hash lengths when leading bytes are zero * Comparison failures for hashes with leading zeros * Potential security issues in hash-based comparisons * Could cause subtle bugs in systems relying on consistent hash lengths Severity is considered low for internal uses of this library but if there's any consumer using these methods directly then this is considered high. ### Patches Upgrade to Jervis 2.2. ### Workarounds Use an alternate SHA-256 hash function or upgrade.

GHSA-crxp-chh4-9ghp: Jervis has Deterministic AES IV Derivation from Passphrase

### Vulnerability https://github.com/samrocketman/jervis/blob/157d2b63ffa5c4bb1d8ee2254950fd2231de2b05/src/main/groovy/net/gleske/jervis/tools/SecurityIO.groovy#L866-L874 https://github.com/samrocketman/jervis/blob/157d2b63ffa5c4bb1d8ee2254950fd2231de2b05/src/main/groovy/net/gleske/jervis/tools/SecurityIO.groovy#L891-L900 Same passphrase + same plaintext = same ciphertext (IV reuse) ### Impact Severity is considered low for internal uses of this library but if there's any consumer using these methods directly then this is considered high. Significant reduction in the security of the encryption scheme. Pattern analysis becomes possible. ### Patches Random IV will be generated and prepended to the ciphertext. Upgrade to Jervis 2.2. ### Workarounds None

GHSA-mqw7-c5gg-xq97: Jervis Has a RSA PKCS#1 Padding Vulnerability

### Vulnerability https://github.com/samrocketman/jervis/blob/157d2b63ffa5c4bb1d8ee2254950fd2231de2b05/src/main/groovy/net/gleske/jervis/tools/SecurityIO.groovy#L463-L465 https://github.com/samrocketman/jervis/blob/157d2b63ffa5c4bb1d8ee2254950fd2231de2b05/src/main/groovy/net/gleske/jervis/tools/SecurityIO.groovy#L495-L497 Uses `PKCS1Encoding` which is vulnerable to Bleichenbacher padding oracle attacks. Modern systems should use OAEP (Optimal Asymmetric Encryption Padding). ### Impact Severity is considered low for internal uses of this library but if there's any consumer using these methods directly then this is considered critical. An attacker with access to a decryption oracle (e.g., timing differences or error messages) could potentially decrypt ciphertext without knowing the private key. Jervis uses RSA to encrypt AES keys in local-only storage inaccessible from the web. The data stored is GitHub App authentication tokens which will expire within one hour or less. ### Pat...