ghsa

### Impact In affected versions, brotli "bombs" (highly compressed brotli streams, such as many zeros) can be sent to the server. Since the server will attempt to decompress these streams before applying various maximums, this can lead to exhaustion of the available memory and thus a Denial of Service. This can be done if the `DSN` is known, which it is in many common setups (JavaScript, Mobile Apps). ### Patches Patched in Bugsink `2.0.5`

### Impact The MongoDB `explain()` method provides detailed information about query execution plans, including index usage, collection scanning behavior, and performance metrics. Parse Server permits any client to execute explain queries without requiring the master key. This exposes: - Database schema structure and field names - Index configurations and query optimization details - Query execution statistics and performance metrics - Potential attack vectors for database performance exploitation ### Patches A new `databaseOptions.allowPublicExplain` configuration option has been introduced that allows to restrict `explain` queries to the master key. The option defaults to `true` for now to avoid a breaking change in production systems that depends on public `explain` availability. In addition, a security warning is logged when the option is not explicitly set, or set to `true`. In a future major release of Parse Server, the default will change to `false`. ### Workarounds Impleme...

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