ghsa

## Summary Before version [v2.11.0](https://github.com/mrousavy/react-native-mmkv/releases/tag/v2.11.0), the react-native-mmkv logged the optional encryption key for the MMKV database into the Android system log. The key can be obtained by anyone with access to the Android Debugging Bridge (ADB) if it is enabled in the phone settings. This bug is not present on iOS devices. ## Details The bridge for communicating between JS code and native code on Android logs the encryption key. This was fixed in commit [a8995cc](https://github.com/mrousavy/react-native-mmkv/commit/a8995ccb7184281f7d168bad3e9987c9bd05f00d) by only logging whether encryption is used. ## Impact The encryption of an MMKV database protects data from higher privilege processes on the phone that can access the app storage. Additionally, if data in the app's storage is encrypted, it is also encrypted in potential backups. By logging the encryption secret to the system logs, attackers can trivially recover the secret by ena...

Microsoft.Data.SqlClient and System.Data.SqlClient SQL Data Provider Security Feature Bypass Vulnerability

### Impact _What kind of vulnerability is it? Who is impacted?_ An attacker could exploit this vulnerability by crafting a malicious JSON Web Encryption (JWE) token with a high compression ratio. This token, when processed by a server, leads to excessive memory allocation and processing time during decompression, causing a denial-of-service (DoS) condition. It's important to note that the attacker must have access to the public encrypt key registered with the IDP(Entra ID) for successful exploitation. _According to the CVSS metric, a successful exploitation could lead to a scope change (S:C). What does this mean for this vulnerability?_ A scope change (S:C) in the CVSS metric indicates that successful exploitation of this vulnerability could extend beyond the immediate processing of malicious tokens, affecting the overall availability of the system by causing a denial-of-service (DoS) condition. ### Patches _Has the problem been patched? What versions should users upgrade to?_ The v...

### Impact _What kind of vulnerability is it? Who is impacted?_ Anyone leveraging the `SignedHttpRequest`protocol or the `SignedHttpRequestValidator`is vulnerable. Microsoft.IdentityModel trusts the `jku`claim by default for the `SignedHttpRequest`protocol. This raises the possibility to make any remote or local `HTTP GET` request. ### Patches _Has the problem been patched? What versions should users upgrade to?_ The vulnerability has been fixed in Microsoft.IdentityModel.Protocols.SignedHttpRequest. Users **should** update **all** their Microsoft.IdentityModel versions to 7.1.2 (for 7x) or higher, 6.34.0 (for 6x) or higher, if using Microsoft.IdentityModel.Protocols.SignedHttpRequest. ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ No, users must upgrade. ### References _Are there any links users can visit to find out more?_ https://aka.ms/IdentityModel/Jan2024/jku

### Summary Calling `jws.Parse` with a JSON serialized payload where the `signature` field is present while `protected` is absent can lead to a nil pointer dereference. ### Details This seems to also affect other functions that calls `Parse` internally, like `jws.Verify`. My understanding of these functions from the docs is that they are supposed to fail gracefully on invalid input and don't require any prior validation. Based on the stack trace in the PoC, the issue seems to be that the processing done in `jws/message.go:UnmarshalJSON()` assumes that if a `signature` field is present, then a `protected` field is also present. If this is not the case, then the subsequent call to `getB64Value(sig.protected)` will dereference `sig.protected`, which is `nil`. ### PoC Reproducer: ```go package poc import ( "testing" "github.com/lestrrat-go/jwx/v2/jws" ) func TestPOC(t *testing.T) { _, _ = jws.Parse([]byte(`{"signature": ""}`)) } ``` Result: ``` $ go tes...

### Summary As of `fonttools>=4.28.2` the subsetting module has a XML External Entity Injection (XXE) vulnerability which allows an attacker to resolve arbitrary entities when a candidate font (OT-SVG fonts), which contains a SVG table, is parsed. This allows attackers to include arbitrary files from the filesystem fontTools is running on or make web requests from the host system. ### PoC The vulnerability can be reproduced following the bellow steps on a unix based system. 1. Build a OT-SVG font which includes a external entity in the SVG table which resolves a local file. In our testing we utilised `/etc/passwd` for our POC file to include and modified an existing subset integration test to build the POC font - see bellow. ```python from string import ascii_letters from fontTools.fontBuilder import FontBuilder from fontTools.pens.ttGlyphPen import TTGlyphPen from fontTools.ttLib import newTable XXE_SVG = """\ <?xml version="1.0"?> <!DOCTYPE svg [<!ENTITY test SYSTEM 'file...

In Appwrite CLI before 3.0.0, when using the login command, the credentials of the Appwrite user are stored in a ~/.appwrite/prefs.json file with 0644 as UNIX permissions. Any user of the local system can access those credentials.

Qualys Jenkins Plugin for Policy Compliance prior to version and including 1.0.5 was identified to be affected by a security flaw, which was missing a permission check while performing a connectivity check to Qualys Cloud Services. This allowed any user with login access and access to configure or edit jobs to utilize the plugin to configure a potential rouge endpoint via which it was possible to control response for certain request which could be injected with XSS payloads leading to XSS while processing the response data.

Qualys Jenkins Plugin for Policy Compliance prior to version and including 1.0.5 was identified to be affected by a security flaw, which was missing a permission check while performing a connectivity check to Qualys Cloud Services. This allowed any user with login access to configure or edit jobs to utilize the plugin and configure potential a rouge endpoint via which it was possible to control response for certain request which could be injected with XXE payloads leading to XXE while processing the response data

Qualys Jenkins Plugin for WAS prior to version and including 2.0.11 was identified to be affected by a security flaw, which was missing a permission check while performing a connectivity check to Qualys Cloud Services. This allowed any user with login access to configure or edit jobs to utilize the plugin and configure potential a rouge endpoint via which it was possible to control response for certain request which could be injected with XXE payloads leading to XXE while processing the response data