ghsa

### Impact A bug was found in containerd's CRI implementation where programs inside a container can cause the containerd daemon to consume memory without bound during invocation of the `ExecSync` API. This can cause containerd to consume all available memory on the computer, denying service to other legitimate workloads. Kubernetes and crictl can both be configured to use containerd's CRI implementation; `ExecSync` may be used when running probes or when executing processes via an "exec" facility. ### Patches This bug has been fixed in containerd 1.6.6 and 1.5.13. Users should update to these versions to resolve the issue. ### Workarounds Ensure that only trusted images and commands are used. ### References * Similar fix in cri-o's CRI implementation https://github.com/cri-o/cri-o/security/advisories/GHSA-fcm2-6c3h-pg6j ### Credits The containerd project would like to thank David Korczynski and Adam Korczynski of ADA Logics for responsibly disclosing this issue in accordan...

### Description An ExecSync request runs a command in a container and returns the output to the Kubelet. It is used for readiness and liveness probes within a pod. The way CRI-O runs ExecSync commands is through conmon. CRI-O asks conmon to start the process, and conmon writes the output to disk. CRI-O then reads the output and returns it to the Kubelet. If the output of the command is large enough, it is possible to exhaust the memory (or disk usage) of the node. The following deployment is an example yaml file that will output around 8GB of ‘A’ characters, which would be written to disk by conmon and read by CRI-O. ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment100 spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 lifecycle: postStart: exec: command: ["/bin/s...

### Impact For a subset of Omnipay gateways (those that use intermediary states like `isNotification()` or `isRedirect()`), if the payment identifier or success URL is exposed it is possible for payments to be prematurely marked as completed without payment being taken. This is mitigated by the fact that most payment gateways hide this information from users, however some issuing banks offer flawed 3DSecure implementations that may inadvertently expose this data. ### Patches The following versions have been patched to fix this issue: - `2.5.2` - `3.0.2` - `3.1.4` - `3.2.1` ### Workarounds There are no known workarounds for this vulnerability. ### References N/A. ### For more information If you have any questions or comments about this advisory: * Email us at [[email protected]](mailto:[email protected])

### Impact It was possible to traverse the entire AWS S3 bucket and in most cases to access or delete files. The issue was discovered by the maintainer. There were no reports of the vulnerability being known to or exploited by a third party, before the release of the patch. If the `AWS_LOCATION` setting was set, traversal was limited to that location only. If all your files handling views (like form views) require authentication or special permission, the thread is limited to privileged users. ### Patches The vulnerability has been fixed in version 5.5.1 and above. ### Workarounds There is no feasible workaround. We must urge all users to immediately updated to a patched version. ### Detailed attack vector description An attacker may use a request with malicious form data to traverse the entire AWS S3 bucket and perform destructive operations. An attack could look as follows: ```bash curl -X POST -F "s3file=file" -F "file=/priviliged/location/secrets.txt" https://www.example.c...

### Impact when a calling an external contract with no return value, the contract address could be evaluated twice. this is usually only an efficiency problem, but if evaluation of the contract address has side effects, it could result in double evaluation of the side effects. in the following example, `Foo(msg.sender).bar()` is the contract address for the following call (to `.foo()`), and could get evaluated twice ```vyper interface Foo: def foo(): nonpayable def bar() -> address: nonpayable @external def do_stuff(): Foo(Foo(msg.sender).bar()).foo() ``` ### Patches v0.3.4 ### Workarounds assign contract addresses to variables. the above example would change to ```vyper @external def do_stuff(): t: Foo = Foo(msg.sender).bar() t.foo() ``` ### References ### For more information

### Impact Under certain conditions, an attacker can construct malicious authentication requests to bypass the authentication process, resulting in privilege escalation or unauthorized access. Only users using TiDB 5.3.0 are affected by this vulnerability. ### Patches Please upgrade to TiDB 5.3.1 or higher version ### Workarounds You can also mitigate risks by taking the following measures. Option 1: Turn off SEM (Security Enhanced Mode). Option 2: Disable local login for non-root accounts and ensure that the same IP cannot be logged in as root or normal user at the same time. ### References https://en.pingcap.com/download/ ### For more information If you have any questions or comments about this advisory: * Email us at [email protected]

### Impact When authenticating, a malicious server could return a specially crafted authentication packet, causing the client to read and return up to 12 bytes of data from an uninitialized variable in stack memory. ### Patches Users of the trilogy gem should upgrade to version 2.1.1 ### Workarounds This issue can be avoided by only connecting to trusted servers. ### Acknowledgements We would like to thank Sergei Volokitin for reporting this vulnerability ### For more information If you have any questions or comments about this advisory: * Open an issue in [trilogy](https://github.com/github/trilogy)

# Background CILogon is a federated auth provider that allows users to authenticate themselves via a number of Identity Providers (IdP), focused primarily on educational and research institutions (such as Universities). More traditional and open IdPs such as GitHub, ORCID, Google, Microsoft, etc are also supported. CILogonOAuthenticator is provided by the OAuthenticator package, and lets users log in to a JupyterHub via CILogon. This is primarily used to restrict a JupyterHub only to users of a given institute. The allowed_idps configuration trait of CILogonOAuthenticator is documented to be a list of domains that indicate the institutions whose users are authorized to access this JupyterHub. This authorization is validated by ensuring that the *email* field provided to us by CILogon has a *domain* that matches one of the domains listed in `allowed_idps`. # Impact If `allowed_idps` contains `berkeley.edu`, you might expect only users with valid current credentials provided by Unive...

FacturaScripts 2022.08 and prior is vulnerable to cross-site scripting. A patch is available on the `master` branch of the repository and anticipated to be part of version 2022.09.

An access control issue in aleksis/core/util/auth_helpers.py: ClientProtectedResourceMixin of AlekSIS-Core v2.8.1 and below allows attackers to access arbitrary scopes if no allowed scopes are specifically set.