ghsa

Open redirect vulnerability in web2py versions prior to 2.22.5 allows a remote attacker to redirect a user to an arbitrary web site and conduct a phishing attack by having a user to access a specially crafted URL.

Cross-site Scripting (XSS) - Generic in GitHub repository ionicabizau/parse-url prior to 6.0.1

Server-Side Request Forgery (SSRF) in GitHub repository ionicabizau/parse-url prior to 7.0.0.

Cross-site Scripting (XSS) - Stored in GitHub repository ionicabizau/parse-url prior to 7.0.0.

Exposure of Sensitive Information to an Unauthorized Actor via hostname confusion in GitHub repository ionicabizau/parse-url prior to 6.0.1

An issue was discovered in SaltStack Salt in versions before 3002.9, 3003.5, 3004.2. PAM auth fails to reject locked accounts, which allows a previously authorized user whose account is locked still run Salt commands when their account is locked. This affects both local shell accounts with an active session and salt-api users that authenticate via PAM eauth.

### Impact A malicious message can crash CloudCore by triggering a null-pointer dereference in the UDS Server. Since the UDS Server only communicates with the CSI Driver on the cloud side, the attack is limited to the local host network. As such, an attacker would already need to be an authenticated user of the Cloud. It will be affected only when users turn on the unixsocket switch in the config file `cloudcore.yaml` as below: ``` modules: cloudHub: ... unixsocket: address: xxx enable: true ``` ### Patches This bug has been fixed in Kubeedge 1.11.0, 1.10.1, and 1.9.3. Users should update to these versions to resolve the issue. ### Workarounds Disable the unixsocket switch of CloudHub in the config file `cloudcore.yaml`. ### References NA ### Credits Thanks David Korczynski and Adam Korczynski of ADA Logics for responsibly disclosing this issue in accordance with the [kubeedge security policy](https://github.com/kubeedge/kubeedge/security/policy) during a se...

### Impact Jsrsasign supports JWS(JSON Web Signatures) and JWT(JSON Web Token) validation. However JWS or JWT signature with non Base64URL encoding special characters or number escaped characters may be validated as valid by mistake. For example, even if a string of non Base64URL encoding characters such as `!@$%` or `\11` is inserted into a valid JWS or JWT signature value string, it will still be a valid JWS or JWT signature by mistake. When jsrsasign's JWS or JWT validation is used in OpenID connect or OAuth2, this vulnerability will affect to authentication or authorization. By our internal assessment, CVSS 3.1 score will be 7.5. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N ### Patches Users validate JWS or JWT signatures should upgrade to 10.5.25. ### Workarounds Validate JWS or JWT signature if it has Base64URL and dot safe string before executing JWS.verify() or JWS.verifyJWT() method. ### ACKNOWLEDGEMENT Thanks to Adi Malyanker and Or David for this vulnerability report...

### Impact The existing URI path filters in OctoRPKI (version < 1.4.3) mitigating Path traversal vulnerability could be bypassed by an attacker. In case a malicious TAL file is parsed, it was possible to write files outside the base cache folder. ### Patches The issue was fixed in version 1.4.3 ### References [CVE-2021-3907](https://www.cvedetails.com/cve/CVE-2021-3907/)

### Impact An authenticated customer can perform SQL injection ### Patches Issue is fixed in 2.1.1