ghsa

Cross-Site Request Forgery (CSRF) in GitHub repository usememos/memos 0.9.0 and prior.

The `parse` method of the JSON5 library before and including version `2.2.1` does not restrict parsing of keys named `__proto__`, allowing specially crafted strings to pollute the prototype of the resulting object. This vulnerability pollutes the prototype of the object returned by `JSON5.parse` and not the global Object prototype, which is the commonly understood definition of Prototype Pollution. However, polluting the prototype of a single object can have significant security impact for an application if the object is later used in trusted operations. ## Impact This vulnerability could allow an attacker to set arbitrary and unexpected keys on the object returned from `JSON5.parse`. The actual impact will depend on how applications utilize the returned object and how they filter unwanted keys, but could include denial of service, cross-site scripting, elevation of privilege, and in extreme cases, remote code execution. ## Mitigation This vulnerability is patched in json v2.2.2 and...

### Impact If you make use of the **report receiver server** (experimental), a client may be able to forge requests such that arbitrary files on the host can be overwritten (subject to permissions of the yapscan server), leading to loss of data. This is particularly problematic if you do not authenticate clients and/or run the server with elevated permissions. ### Patches Vulnerable versions: - v0.18.0 - v0.19.0 (unreleased) This problem is patched in version v0.19.1 ### Workarounds Update to the newer version is highly encouraged! Measures to reduce the risk of this include authenticating clients (see `--client-ca` flag) and containerization of the yapscan server. ### References The tracking issue is #35. There you can find the commits, fixing the issue.

### Impact It is possible to craft an environment variable with newlines to add entries to a container's /etc/passwd. It is possible to circumvent admission validation of username/UID by adding such an entry. Note: because the pod author is in control of the container's /etc/passwd, this is not considered a new risk factor. However, this advisory is being opened for transparency and as a way of tracking fixes. ### Patches 1.26.0 will have the fix. More patches will be posted as they're available. ### Workarounds Additional security controls like SELinux should prevent any damage a container is able to do with root on the host. Using SELinux is recommended because this class of attack is already possible by manually editing the container's /etc/passwd ### References

### Impact The vulnerability may allow a remote attacker to terminate the application with a stack overflow error resulting in a denial of service only by manipulating the processed input stream. ### Patches XStream 1.4.20 handles the stack overflow and raises an InputManipulationException instead. ### Workarounds The attack uses the hash code implementation for collections and maps to force recursive hash calculation causing a stack overflow. Following types of the Java runtime are affected: - java.util.HashMap - java.util.HashSet - java.util.Hashtable - java.util.LinkedHashMap - java.util.LinkedHashSet - Other third party collection implementations that use their element's hash code may also be affected A simple solution is to catch the StackOverflowError in the client code calling XStream. If your object graph does not use referenced elements at all, you may simply set the NO_REFERENCE mode: ```Java XStream xstream = new XStream(); xstream.setMode(XStream.NO_REFERENCES); ``` I...

Improper Access Control in GitHub repository usememos/memos 0.9.0 and prior.

An Insufficient Granularity of Access Control in usememos/memos prior to 0.9.0 can allow an attacker to delete a memo from the archives.

In usememos/memos 0.9.0 and prior, an unauthorized user can access any private memo by URL hacking a memo on the editing screen.

An Improper Access Control vulnerability in usememos/memos 0.9.0 and prior can result in a user deleting others' public and private memos.

usememos/memos 0.9.0 and prior is vulnerable to full account takeover via changing user name, email address, and display name.