ghsa

An arbitrary file upload vulnerability in the background management module of RuoYi v4.7.3 and below allows attackers to execute arbitrary code via a crafted HTML file.

### Impact This advisory affects plugins that expose the `October\Rain\Database\Attach\File::fromData` as a public interface. This vulnerability does not affect vanilla installations of October CMS since this method is not exposed or used by the system internally or externally. When the developer allows the user to specify their own filename in the `fromData` method, an unauthenticated user can perform remote code execution (RCE) by exploiting a race condition in the temporary storage directory. ### Patches The issue has been patched in Build 476 (v1.0.476) and v1.1.12 and v2.2.15. ### Workarounds Apply https://github.com/octobercms/library/commit/fe569f3babf3f593be2b1e0a4ae0283506127a83 to your installation manually if unable to upgrade to Build 476 (v1.0.476) or v1.1.12 or v2.2.15. ### References Credits to: - DucNT, HungTD and GiangVQ from RedTeam@VNG Security Response Center. ### For more information If you have any questions or comments about this advisory: - Email us at...

The ganga-devs/ganga repository before 8.5.10 on GitHub allows absolute path traversal because the Flask send_file function is used unsafely.

The package svelte before 3.49.0 is vulnerable to Cross-site Scripting (XSS) due to improper input sanitization and to improper escape of attributes when using objects during SSR (Server-Side Rendering). Exploiting this vulnerability is possible via objects with a custom toString() function.

A security issue was discovered in aws-iam-authenticator where an allow-listed IAM identity may be able to modify their username and escalate privileges.

### Overview Affected versions have no limit to using unsafe-accessor. Can be ignored if `SecurityCheck.AccessLimiter` not setup ### Details If UA was loaded as a named module, the internal data of UA will be protected by JVM and others can only access UA via UA's standard api. Main application can setup `SecurityCheck.AccessLimiter` for UA to limit accesses to UA. Untrusted code can access UA without lmitation in affected versions even UA was loaded as a named module. ### References [The commit to fix](https://github.com/Karlatemp/UnsafeAccessor/commit/4ef83000184e8f13239a1ea2847ee401d81585fd)

```php <?php namespace My\App; use CuyZ\Valinor\Mapper\MappingError; use CuyZ\Valinor\Mapper\Tree\Node; use CuyZ\Valinor\Mapper\Tree\NodeTraverser; use CuyZ\Valinor\MapperBuilder; require_once __DIR__ . '/Valinor/vendor/autoload.php'; final class Money { private function __construct(public readonly string $amount) { } public static function fromString(string $money): self { if (1 !== \preg_match('/^\d+ [A-Z]{3}$/', $money)) { throw new \InvalidArgumentException(\sprintf('Given "%s" is not a recognized monetary amount', $money)); } return new self($money); } } class Foo { public function __construct( private readonly Money $a, private readonly Money $b, private readonly Money $c, ) {} } $mapper = (new MapperBuilder()) ->registerConstructor([Money::class, 'fromString']) ->mapper(); try { var_dump($mapper->map(Foo::class, [ 'a' => 'HAHA', 'b' => '100 EUR...

### Impact All versions of Argo CD starting with 2.3.0 are vulnerable to a cross-site scripting (XSS) bug which could allow an attacker to inject arbitrary JavaScript in the `/auth/callback` page in a victim's browser. This vulnerability only affects Argo CD instances which have SSO enabled. The exploit also assumes the attacker has 1) access to the API server's encryption key, 2) a method to add a cookie to the victim's browser, and 3) the ability to convince the victim to visit a malicious `/auth/callback` link. The vulnerability is classified as low severity, because access to the API server's encryption key already grants a high level of access. Exploiting the XSS would allow the attacker to impersonate the victim, but would not grant any privileges which the attacker could not otherwise gain using the encryption key. ### Patches A patch for this vulnerability has been released in the following Argo CD versions: * v2.4.5 * v2.3.6 ### Workarounds There is no workaround bes...

### Impact All versions of Argo CD starting with v0.4.0 are vulnerable to an improper certificate validation bug which could cause Argo CD to trust a malicious (or otherwise untrustworthy) OIDC provider. (Note: external OIDC provider support was added in v0.11.0. Before that version, the notes below apply only to the bundled Dex instance.) You are impacted if 1) have SSO enabled and 2) insecure mode is _not_ enabled on the API server. In this case, certificate verification is skipped when connecting to your OIDC provider for the following tasks: verifying auth tokens on API requests and handling SSO login flows. If you are using the bundled Dex instance but have _not_ set the `--dex-server` flag on the API server to an HTTPS address, then certificate verification is not being skipped (because [TLS is not enabled by default for the bundled Dex instance](https://github.com/argoproj/argo-cd/issues/9424)). Argo CD sends requests to the configured OIDC provider (either the bundled Dex i...

When serialized columns that use YAML (the default) are deserialized, Rails uses YAML.unsafe_load to convert the YAML data in to Ruby objects. If an attacker can manipulate data in the database (via means like SQL injection), then it may be possible for the attacker to escalate to an RCE. There are no feasible workarounds for this issue, but other coders (such as JSON) are not impacted.