ghsa

Static Code Injection in GitHub repository froxlor/froxlor prior to 2.0.10.

Unchecked Error Condition in GitHub repository froxlor/froxlor prior to 2.0.10.

Weak Password Requirements in GitHub repository publify/publify prior to 9.2.10.

loadAsync in JSZip before 3.8.0 allows Directory Traversal via a crafted ZIP archive.

Weak Password Requirements in GitHub repository froxlor/froxlor prior to 2.0.10.

A vulnerability has been found in NYUCCL psiTurk up to 3.2.0 and classified as critical. This vulnerability affects unknown code of the file psiturk/experiment.py. The manipulation of the argument mode leads to improper neutralization of special elements used in a template engine. The exploit has been disclosed to the public and may be used. Upgrading to version 3.2.1 is able to address this issue. The name of the patch is 47787e15cecd66f2aa87687bf852ae0194a4335f. It is recommended to upgrade the affected component. The identifier of this vulnerability is VDB-219676.

### Impact Using carefully crafted input, an attacker may be able to sneak arbitrary HTML through Sanitize `>= 5.0.0, < 6.0.1` when Sanitize is configured with a custom allowlist that allows `noscript` elements. This could result in XSS (cross-site scripting) or other undesired behavior when that HTML is rendered in a browser. Sanitize's default configs don't allow `noscript` elements and are not vulnerable. This issue only affects users who are using a custom config that adds `noscript` to the element allowlist. ### Patches Sanitize `>= 6.0.1` always removes `noscript` elements and their contents, even when `noscript` is in the allowlist. ### Workarounds Users who are unable to upgrade can prevent this issue by using one of Sanitize's default configs or by ensuring that their custom config does not include `noscript` in the element allowlist. ### Details The root cause of this issue is that HTML parsing rules treat the contents of a `noscript` element differently depending on ...

In Eclipse GlassFish versions 5.1.0 to 6.2.5, there is a vulnerability in relative path traversal because it does not filter request path starting with './'. Successful exploitation could allow an remote unauthenticated attacker to access critical data, such as configuration files and deployed application source code.

### Description In SafeURL it is possible to specify a list of domains that should be matched before a request is sent out. The regex used to compare domains did not work as intended. ### Impact The regex used was: `re.match("(?i)^%s" % domain, value)` This has two problems, first that only the beginning and not the end of the string is anchored. Second, that a dot in the domain matches any character as part of regex syntax. Therefore, an allowlist of ["victim.com"] could allow the domain "victimacomattacker.com" to be requested. This has lower impact since the usual attacker aim in an SSRF is to request internal resources such as private IP addresses rather than an attacker's own domain. But, in a case where SafeURL had specifically been used to try to limit requests to a particular allowlist, say for example a PDF renderer, the finding would be more severe. ### Patches Fixed in https://github.com/IncludeSecurity/safeurl-python/pull/5 ### References [Server-side request forgery...

### Impact An administrator with the permissions to upload files via DataFlow and to create products was able to execute arbitrary code via the convert profile.