ghsa

### Impact If a field of a key is shorter than it is declared to be, the parser raises an error with a message containing the raw field value. An attacker able to modify the declared length of a key's sensitive field can thus expose the raw value of that field. ### Patches Upgrade to version 0.0.6, which no longer includes the raw field value in the error message. ### Workarounds N/A ### References N/A ### For more information If you have any questions or comments about this advisory: * Open an issue in [openssh_key_parser](https://github.com/scottcwang/openssh_key_parser)

### Impact * using string-to-date parsing in moment (more specifically rfc2822 parsing, which is tried by default) has quadratic (N^2) complexity on specific inputs * noticeable slowdown is observed with inputs above 10k characters * users who pass user-provided strings without sanity length checks to moment constructor are vulnerable to (Re)DoS attacks ### Patches The problem is patched in 2.29.4, the patch can be applied to all affected versions with minimal tweaking. ### Workarounds In general, given the proliferation of ReDoS attacks, it makes sense to limit the length of the user input to something sane, like 200 characters or less. I haven't seen legitimate cases of date-time strings longer than that, so all moment users who do pass a user-originating string to constructor are encouraged to apply such a rudimentary filter, that would help with this but also most future ReDoS vulnerabilities. ### References There is an excellent writeup of the issue here: https://github.com/mo...

NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This only applies when lxml is used together with libxml2 2.9.10 through 2.9.14. libxml2 2.9.9 and earlier are not affected. It allows triggering crashes through forged input data, given a vulnerable code sequence in the application. The vulnerability is caused by the iterwalk function (also used by the canonicalize function). Such code shouldn't be in wide-spread use, given that parsing + iterwalk would usually be replaced with the more efficient iterparse function. However, an XML converter that serialises to C14N would also be vulnerable, for example, and there are legitimate use cases for this code sequence. If untrusted input is received (also remotely) and processed via iterwalk function, a crash can be triggered.

An Access Control vulnerability exists in Nacos 2.0.3 in the access prompt page; enter username and password, click on login to capture packets and then change the returned package, which lets a malicious user login.

Old session tokens can be used to authenticate to the application and send authenticated requests.

Nakama Console does not enforce any limit for the number of unsuccessful login attempts.

**Summary** The issue is the same as CVE-2021-43306: An exponential ReDoS (Regular Expression Denial of Service) can be triggered in the jquery-validation npm package, when an attacker is able to supply arbitrary input to the url2 method The fix for CVE-2021-43306, which was suggested by me ([@erik-krogh](https://github.com/erik-krogh)), was incomplete. I didn't know at the time that the fix was incomplete, but the ReDoS analysis in CodeQL has improved since then. **Details** Issue: ReDoS in url2.js (GHSL-2022-039) Below is a PoC that contains the relevant regular expression. Run following script with node and you will notice that it doesn't terminate. ```js const reg = /^(?:(?:(?:https?|ftp):)?\/\/)(?:\S+(?::\S*)?@)?(?:(?!(?:10|127)(?:\.\d{1,3}){3})(?!(?:169\.254|192\.168)(?:\.\d{1,3}){2})(?!172\.(?:1[6-9]|2\d|3[0-1])(?:\.\d{1,3}){2})(?:[1-9]\d?|1\d\d|2[01]\d|22[0-3])(?:\.(?:1?\d{1,2}|2[0-4]\d|25[0-5])){2}(?:\.(?:[1-9]\d?|1\d\d|2[0-4]\d|25[0-4]))|(?:(?:[a-z0-9\u00a1-\uffff][a-z0-...

### Impact pycares versions < 4.2.0 are affected by [CVE-2021-3672](https://nvd.nist.gov/vuln/detail/CVE-2021-3672). ### Patches Update to version 4.2.0.

### Impact _What kind of vulnerability is it? Who is impacted?_ Anyone parsing JSON from an untrusted source is vulnerable. JSON strings that contain escaped surrogate characters not part of a proper surrogate pair were decoded incorrectly. Besides corrupting strings, this allowed for potential key confusion and value overwriting in dictionaries. Examples: ```python # An unpaired high surrogate character is ignored. >>> ujson.loads(r'"\uD800"') '' >>> ujson.loads(r'"\uD800hello"') 'hello' # An unpaired low surrogate character is preserved. >>> ujson.loads(r'"\uDC00"') '\udc00' # A pair of surrogates with additional non surrogate characters pair up in spite of being invalid. >>> ujson.loads(r'"\uD800foo bar\uDC00"') 'foo bar𐀀' ``` ### Patches _Has the problem been patched? What versions should users upgrade to?_ Users should upgrade to UltraJSON 5.4.0. From version 5.4.0, UltraJSON decodes lone surrogates in the same way as the standard library's `json` module does, preserving...

### Impact _What kind of vulnerability is it? Who is impacted?_ When an error occurs while reallocating the buffer for string decoding, the buffer gets freed twice. Due to how UltraJSON uses the internal decoder, this double free is impossible to trigger from Python. ### Patches _Has the problem been patched? What versions should users upgrade to?_ Users should upgrade to UltraJSON 5.4.0. ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ There is no workaround. ### For more information If you have any questions or comments about this advisory: * Open an issue in [UltraJSON](http://github.com/ultrajson/ultrajson/issues)