Threats Tagged 'packagist'

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-957r-qf9p-67xw. This link is maintained to preserve external references. ## Original Description Craft CMS 5.0.0-RC1 before 5.10.6 and 4.0.0-RC1 before 4.18.2 contain an arbitrary file read vulnerability. The create() Twig function restricts class instantiation using a 5-entry blocklist that does not include SplFileObject, allowing an authenticated administrator (with allowAdminChanges=true) to configure a malicious entry type title or URI format that instantiates SplFileObject in a non-sandboxed template context. When a user subsequently creates an entry in the affected section, arbitrary files on the server (such as .env containing the security key and database credentials) are read and rendered as entry titles.

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-f5wm-88jv-g5hx. This link is maintained to preserve external references. ## Original Description Craft CMS versions >= 5.0.0-RC1 before 5.10.7 and >= 4.0.0-RC1 before 4.18.3 contain a remote code execution vulnerability in the Twig sandbox mechanism. Because Craft marks the ElementInterface as safe (via the AllowedInSandbox attribute) and the sandbox allowlisting extends to the entire class hierarchy (craft\base\Component up to yii\base\Component), an authenticated attacker with permission to access the control panel can render a malicious Twig template that abuses the yii\base\Component arbitrary function-call gadget to execute arbitrary code, even when the Twig sandbox is enabled via enableTwigSandbox().

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-596p-6jv8-775v. This link is maintained to preserve external references. ## Original Description Craft CMS versions >= 5.0.0-RC1 before 5.10.6 and >= 4.0.0-RC1 before 4.18.2 interpolate environment variables and secrets (via ${ENV_VAR} strings in the elementId parameter) into Twig templates before rendering, even when the Twig sandbox is enabled. An authenticated attacker with control panel access can render a malicious sandboxed Twig template and, using a blind error-based technique across many requests, incrementally leak arbitrary environment variables and secrets. These can be abused to forge sessions (via CRAFT_SECURITY_KEY), escalate privileges, and steal database, SMTP, API, or blob storage credentials. Fixed in 5.10.6 and 4.18.2.

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-265m-7826-wjqm. This link is maintained to preserve external references. ## Original Description Craft CMS versions from 4.0.0-RC1 before 4.18.2 and from 5.0.0-RC1 before 5.10.6 contain an authenticated remote code execution vulnerability in the control panel element-search condition handling. Craft cleanses the outer request-controlled condition array via Component::cleanseConfig(), but Conditions::createCondition() later decodes and merges the JSON string in condition.config without re-running cleanseConfig() on the decoded configuration. Because condition.config is a JSON string during the first cleanse, Yii special config keys such as 'as ...' and 'on ...' can be hidden inside it and, after JSON decoding, are interpreted by Yii as behavior/event configuration during FieldLayout object creation. An attacker with an authenticated control panel session (and a valid CSRF token) can exploit this to execute operating system commands as the PHP/web user.

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-xxpx-f366-4xpq. This link is maintained to preserve external references. ## Original Description Craft CMS 5.0.0-RC1 through 5.10.5 contains an incorrect authorization vulnerability. A control-panel user holding only the viewCategories permission (without saveCategories) for a category group can permanently modify that group's category structure — reordering and re-parenting categories — via the structures/move-element action. The structureEditable flag is computed from the view permission rather than the save permission, and the StructuresController authorizes the mutating action on that read-time session grant without a save re-check. Because a category's URI is derived from its position in the structure, moving a category changes its URL and those of its descendants and can corrupt navigation menus built from the category taxonomy. The issue is fixed in 5.10.6.

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-7hxc-f267-h5q7. This link is maintained to preserve external references. ## Original Description Craft CMS versions >= 5.0.0-RC1 before 5.10.6 and >= 4.0.0-RC1 before 4.18.2 contain a theoretical path traversal weakness in the ensurePathIsContained function of the Local file system class. The order of operations validates the path before normalization, so normalization could invalidate prior validation assumptions (a desanitization-style issue) and potentially resolve to files outside the intended volume directory. The vendor notes the issue is not directly exploitable and no exploitable scenario has been discovered; the fix is recommended for hardening.

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-68jx-f42c-7599. This link is maintained to preserve external references. ## Original Description The referrer enforcement introduced with TYPO3-CORE-SA-2020-006 (CVE-2020-11069) became ineffective in TYPO3 v13.0, where TYPO3 CMS started serving the backend and Install Tool applications from the site's main entry script instead of the dedicated typo3/ directory. Whether a request originated from the backend or Install Tool itself was determined by comparing the referrer against the directory of the entry script, which since then is the site root. As a consequence, requests originating from any script running on one of the TYPO3 instance's own domains, such as a frontend page, were accepted by backend routes and Install Tool endpoints. Attackers able to execute JavaScript on one of those domains, for instance by exploiting a cross-site scripting vulnerability, could invoke these endpoints via Fetch/XHR with the privileges of an authenticated victim's user session. This issue affects TYPO3 CMS versions 13.0.0-13.4.33 and 14.0.0-14.3.5.

Filament is a collection of full-stack components for accelerated Laravel development. From 4.0.0 until 4.12.6 and 5.7.6, packages/panels/src/Auth/MultiFactor/App/AppAuthentication.php uses AppAuthentication::verifyCode() with a used-code cache key derived from both the app authentication secret and the submitted TOTP code. This isolates the newest accepted timestep by code instead of by secret, allowing a previously issued app-based MFA code to be accepted after a newer code has already been used. Reuse of the exact same code was already prevented, but another code inside the accepted time window remained usable. An attacker who obtains the target account's password and one app-based MFA code can use that code for the remainder of the configured window, which is approximately four minutes with the default settings, even after the legitimate account holder logs in with a newer code. Email-based MFA is not affected. This issue is fixed in versions 4.12.6 and 5.7.6.

Filament is a collection of full-stack components for accelerated Laravel development. From 4.0.0 until 4.12.5 and 5.7.5, packages/panels/src/Auth/Pages/Login.php presents the multi-factor authentication challenge before evaluating canAccessPanel(). For an account that canAccessPanel() denies, submitting the correct password renders the MFA challenge while an incorrect password returns the generic authentication failure, allowing an unauthenticated attacker to confirm whether a candidate password is valid for that account. When email-based MFA is configured, the correct-password path also sends a login code to the account holder. The issue applies only to accounts that have MFA enabled and are denied panel access. Authentication is not bypassed because canAccessPanel() still runs after the challenge, and no session is created. This issue is fixed in versions 4.12.5 and 5.7.5.

### Impact `RSACrypt::decryptWithRSA15()` (used by the `RSA1_5` key-encryption algorithm) implements RSAES-PKCS1-v1_5 decryption by inspecting the padding after RSADP and throwing `InvalidArgumentException` as soon as the padding is malformed. It does **not** implement the implicit-rejection countermeasure required by RFC 3447 §7.2.2 / RFC 8017 §7.1.2 (return a deterministic pseudo-random value of the expected length on padding failure and let the downstream step fail uniformly). From a JWE caller this yields a Bleichenbacher/Marvin padding oracle: an attacker submitting adaptively crafted `encrypted_key` values can distinguish (a) padding rejected, (b) padding valid but wrong CEK length, and (c) padding valid and full AEAD executed — even though `JWEDecrypter` returns the same `false` in all cases — because each path performs a measurably different amount of work, amplifiable by enlarging the ciphertext (CWE-208 timing side channel). Enough adaptive queries can recover the wrapped CEK. ### Affected configurations Applications that register `RSA1_5` in their decryption `AlgorithmManager` and hold an RSA private key. ### Patches PKCS#1 v1.5 decryption now performs implicit rejection: on invalid padding (or unexpected recovered length) it returns a random CEK of the expected size selected in constant time, so the full content-decryption (AEAD) step always runs and fails uniformly, removing the observable difference between padding-valid and padding-invalid ciphertexts. Users are still strongly encouraged to migrate to `RSA-OAEP`. ### Workarounds Prefer `RSA-OAEP`/`RSA-OAEP-256`; do not enable `RSA1_5` for untrusted tokens. ### References - RFC 3447 §7.2.2 / RFC 8017 §7.1.2 - Bleichenbacher (1998); Marvin attack - CWE-208: Observable Timing Discrepancy ## Résolution Un correctif a été préparé sur une branche dédiée basée sur `3.4.x`, avec des tests anti-régression dédiés (fork privé temporaire de cette advisory, PR #1). **RSA1_5** — déchiffrement PKCS#1 v1.5 avec *implicit rejection* en temps constant (RFC 3447 §7.2.2) : un padding invalide n'est plus distinguable d'un padding valide, neutralisant l'oracle Bleichenbacher. **Validation :** `php -l` OK, PHPUnit vert, aucune nouvelle erreur PHPStan introduite (différentiel nul vs `3.4.x`), aucun commentaire ajouté dans le code source. Après merge, cascade prévue `3.4.x → 4.0.x → 4.1.x`.