ghsa

Calls to `cng.TLS1PRF` don't release the key handle, producing a small memory leak every time.

## Summary `Rack::CommonLogger` can be exploited by crafting input that includes newline characters to manipulate log entries. The supplied proof-of-concept demonstrates injecting malicious content into logs. ## Details When a user provides the authorization credentials via `Rack::Auth::Basic`, if success, the username will be put in `env['REMOTE_USER']` and later be used by `Rack::CommonLogger` for logging purposes. The issue occurs when a server intentionally or unintentionally allows a user creation with the username contain CRLF and white space characters, or the server just want to log every login attempts. If an attacker enters a username with CRLF character, the logger will log the malicious username with CRLF characters into the logfile. ## Impact Attackers can break log formats or insert fraudulent entries, potentially obscuring real activity or injecting malicious data into log files. ## Mitigation - Update to the latest version of Rack.

The Temporal api-go library prior to version 1.44.1 did not send `update response` information to Data Converter when the proxy package within the api-go module was used in a gRPC proxy prior to transmission. This resulted in information contained within the `update response` field not having Data Converter transformations (e.g. encryption) applied. This is an issue only when using the UpdateWorkflowExecution APIs (released on 13th January 2025) with a proxy leveraging the api-go library before version 1.44.1. Other data fields were correctly sent to Data Converter. This issue does not impact the Data Converter server. Data was encrypted in transit. Temporal Cloud services are not impacted.

An issue in Anyscale Inc Ray between v.2.9.3 and v.2.40.0 allows a remote attacker to execute arbitrary code via a crafted script.

### Impact The search end-point response headers contain information about Elasticsearch software in use. This information is sensitive from a security point of view because it allows software used by the server to be easily identified. ### Patches GeoNetwork 4.4.5 / 4.2.10 ### Workarounds None ### References - [CVE-2024-32037](https://www.cve.org/CVERecord?id=CVE-2024-32037) - [Search service](https://docs.geonetwork-opensource.org/4.4/api/search/) ### Credits - [Ministry of Economic Affairs and Climate Policy](https://www.rijksoverheid.nl/ministeries/ministerie-van-economische-zaken-en-klimaat), The Netherlands.

Adobe Commerce versions 2.4.7-beta1, 2.4.7-p3, 2.4.6-p8, 2.4.5-p10, 2.4.4-p11 and earlier are affected by an Improper Authorization vulnerability that could result in Privilege escalation. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized access. Exploitation of this issue does not require user interaction. A successful attacker can abuse this to achieve session takeover, increasing the confidentiality and integrity impact as high.

Apache NiFi 1.16.0 through 1.28.0 and 2.0.0-M1 through 2.0.0-M4 include optional debug logging of Parameter Context values during the flow synchronization process. An authorized administrator with access to change logging levels could enable debug logging for framework flow synchronization, causing the application to write Parameter names and values to the application log. Parameter Context values may contain sensitive information depending on application flow configuration. Deployments of Apache NiFi with the default Logback configuration do not log Parameter Context values. Upgrading to Apache NiFi 2.0.0 or 1.28.1 is the recommendation mitigation, eliminating Parameter value logging from the flow synchronization process regardless of the Logback configuration.

### Impact Applications which have been bootstrapped by the new igniter installer (since AshAuthentication v4.1.0) and who have used the magic link strategy _or_ are manually revoking tokens are affected by revoked tokens being allowed to verify as valid. If you did not use the new installer, then you are absolutely not affected. Additionally, unless you have implemented any kind of custom token revocation feature in your application (in which case even cursory testing would have uncovered this issue), then you will not be significantly affected. The impact here for users using builtin functionality is that magic link tokens are reusable until they expire instead of being immediately revoked. Magic link tokens are only valid for 10 minutes, so the surface area for abuse is extremely low here. ### Patches The flaw is patched in version 4.4.9. Additionally a compile time warning is shown to users with remediation instructions if they upgrade. 4.4.9 ships with an upgrader, so if you u...

pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in cryptography 42.0.0-44.0.0 are vulnerable to a security issue. More details about the vulnerability itself can be found in https://openssl-library.org/news/secadv/20250211.txt. If you are building cryptography source ("sdist") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.

### Impact Systems running registry version > `3.0.0-beta.1` with token authentication enabled. ### Patches Update to at least `v3.0.0-rc.3` ### Workarounds There is no way to work around this issue without patching if your system requires token authentication. ### References The issue lies in how the JWK verification is performed. When a JWT contains a JWK header without a certificate chain, the code only checks if the KeyID (`kid`) matches one of the trusted keys, but doesn't verify that the actual key material matches. Here's the problematic flow: 1. An attacker generates their own key pair 2. They create a JWT and include their public key in the JWK header 3. They set the `kid` in the JWK to match one of the trusted keys' IDs (which they could potentially discover) 4. They sign the JWT with their private key 5. The registry only checks if the `kid` exists in the trusted keys map but then uses the attacker's public key from the JWK to verify the signature