ghsa

### Description The `Request` class improperly interprets some `PATH_INFO` in a way that leads to representing some URLs with a path that doesn't start with a `/`. This can allow bypassing some access control rules that are built with this `/`-prefix assumption. ### Resolution The `Request` class now ensures that URL paths always start with a `/`. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/9962b91b12bb791322fa73836b350836b6db7cac) for branch 5.4. ### Credits We would like to thank Andrew Atkinson for discovering the issue, Chris Smith for reporting it and Nicolas Grekas for providing the fix.

### Summary A vulnerability was identified in the `evervault-go` SDK’s attestation verification logic that may allow incomplete documents to pass validation. This may cause the client to trust an enclave operator that does not meet expected integrity guarantees. The exploitability of this issue is limited in Evervault-hosted environments as an attacker would require the pre-requisite ability to serve requests from specific evervault domain names, following from our ACME challenge based TLS certificate acquisition pipeline. The vulnerability primarily affects applications which only check PCR8. Though the efficacy is also reduced for applications that check all PCR values, the impact is largely remediated by checking PCR 0, 1 and 2. ### Patches The identified issue has been addressed in version [1.3.2](https://github.com/evervault/evervault-go/pull/48) by validating attestation documents before storing in the cache, and replacing the naive equality checks with a new SatisfiedBy c...

### Impact All deployments of OAuth2 Proxy in front of applications that normalize underscores to dashes in HTTP headers (e.g., WSGI-based frameworks such as Django, Flask, FastAPI, and PHP applications). Authenticated users can inject underscore variants of X-Forwarded-* headers that bypass the proxy’s filtering logic, potentially escalating privileges in the upstream app. OAuth2 Proxy authentication/authorization itself is not compromised. ### Patches This change mitigates a request header smuggling vulnerability where an attacker could bypass header stripping by using different capitalization or replacing dashes with underscores. The problem has been patched with v7.13.0. By default all specified headers will now be normalized, meaning that both capitalization and the use of underscores (_) versus dashes (-) will be ignored when matching headers to be stripped. For example, both `X-Forwarded-For` and `X_Forwarded-for` will now be treated as equivalent and stripped away. However...

### Impact Wasmtime's Rust embedder API contains an unsound interaction where a WebAssembly shared linear memory could be viewed as a type which provides safe access to the host (Rust) to the contents of the linear memory. This is not sound for shared linear memories, which could be modified in parallel, and this could lead to a data race in the host. Wasmtime has a `wasmtime::Memory` type which represents linear memories in a WebAssembly module. Wasmtime also has `wasmtime::SharedMemory`, however, which represents shared linear memories introduced in the WebAssembly `threads` proposal. The API of `SharedMemory` does not provide accessors which return `&[u8]` in Rust, for example, as that's not a sound type signature when other threads could be modifying memory. The `wasmtime::Memory` type, however, does provide this API as it's intended to be used with non-shared memories where static knowledge is available that no concurrent or parallel reads or writes are happening. This means tha...

### Summary If a user begins entering a password but does not press return for an extended period, a password timeout may occur. When this happens, the keystrokes that were entered are echoed back to the console. ### Example Using sudo-rs: ``` geiger@cerberus:~$ sudo -s [sudo: authenticate] Password: sudo-rs: timed out geiger@cerberus:~$ testtesttest ``` "testtesttest" was entered at the password prompt but not confirmed by pressing return and then waiting for the timeout. ### Impact This could reveal partial password information, possibly exposing history files when not carefully handled by the user and on screen, usable for Social Engineering or Pass-By attacks. ### Versions affected Passwords timeouts were added in sudo-rs 0.2.7 (with a default set to 5 minutes). ### Credits This issue was discovered and reported by @DevLaTron.

### Summary If the "claims_parameter_supported" parameter is activated, it is possible through the "oidc-claims-extension.groovy" script, to inject the value of choice into a claim contained in the id_token or in the user_info. Authorization function requests do not prevent a claims parameter containing a JSON file to be injected. This JSON file allows users to customize claims returned by the "id_token" and "user_info" files. This allows for a very wide range of vulnerabilities depending on how clients use claims. For example, if some clients rely on an email field to identify a user, users can choose to entera any email address, and therefore assume any chosen identity.

### Summary A Stored Cross Site Scripting is present in the changedetection.io Watch update API due to unsufficient security checks. ### Details Tested on changedetection.io version *v0.50.24* ```console REPOSITORY TAG IMAGE ID CREATED SIZE ghcr.io/dgtlmoon/changedetection.io latest 0367276509a0 23 hours ago 599MB ``` When a user tries to add an unsafe URL as a Watch in the changedetection.io UI, the action is blocked with the error message "Watch protocol is not permitted by SAFE_PROTOCOL_REGEX or incorrect URL format". This is catched by the function `validate_url(test_url)`. ```python def validate_url(test_url): # ... from .model.Watch import is_safe_url if not is_safe_url(test_url): # This should be wtforms.validators. raise ValidationError('Watch protocol is not permitted by SAFE_PROTOCOL_REGEX or incorrect URL format') ``` When instead the Watch API is used, this check is not performed resul...

SUMMARY We have identified and verified an SSRF vulnerability where webhook URLs are not validated, allowing repository administrators to create webhooks targeting internal services, private networks, and cloud metadata endpoints. AFFECTED COMPONENTS (VERIFIED) 1. Webhook Creation (pkg/ssh/cmd/webhooks.go:125) 2. Backend CreateWebhook (pkg/backend/webhooks.go:17) 3. Backend UpdateWebhook (pkg/backend/webhooks.go:122) 4. Webhook Delivery (pkg/webhook/webhook.go:97) IMPACT This vulnerability allows repository administrators to perform SSRF attacks, potentially enabling: a) Cloud Metadata Theft - Access AWS/Azure/GCP credentials via 169.254.169.254 b) Internal Network Access - Target localhost and private networks (10.x, 192.168.x, 172.16.x) c) Port Scanning - Enumerate internal services via response codes and timing d) Data Exfiltration - Full HTTP responses stored in webhook delivery logs e) Internal API Access - Call internal admin panels and Kubernetes endpoints PROOF OF CONCE...

### Summary An authenticated SQL injection vulnerability exists in the moderator control panel (`modcp.php`). Users with moderator permissions can exploit this vulnerability by supplying a malicious `topic_id` (`t`) parameter. This allows an authenticated moderator to execute arbitrary SQL queries, leading to the potential disclosure, modification, or deletion of any data in the database. ### Details The vulnerability is triggered when `modcp.php` processes a request that includes a `topic_id` (`t` parameter). The value of `$topic_id` is taken directly from user input and is not sanitized or parameterized before being concatenated into an SQL query. This occurs within the initial data retrieval block for a given topic ID. **Vulnerable Code Block in `modcp.php` (lines 111-122):** ```php if ($topic_id) { $sql = " SELECT f.forum_id, f.forum_name, f.forum_topics, f.self_moderated, t.topic_first_post_id, t.topic_poster FROM " . BB_TOPICS . " t, " . BB_FORUMS . " f WHERE t...

### Impact The XML [`Validator`](https://docs.oracle.com/javase/8/docs/api/javax/xml/validation/Validator.html) used by cyclonedx-core-java was not configured securely, making the library vulnerable to XML External Entity (XXE) injection. The fix for GHSA-683x-4444-jxh8 / CVE-2024-38374 has been incomplete in that it only fixed *parsing* of XML BOMs, but not *validation*. ### Patches The vulnerability has been fixed in cyclonedx-core-java version 11.0.1. ### Workarounds If feasible, applications can reject XML documents before handing them to cyclonedx-core-java for validation. This may be an option if incoming CycloneDX BOMs are known to be in JSON format. ### References * The issue was introduced via https://github.com/CycloneDX/cyclonedx-core-java/commit/162aa594f347b3f612fe0a45071693c3cd398ce9 * The issue was fixed via https://github.com/CycloneDX/cyclonedx-core-java/pull/737 * https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#sc...