GitHub Advisory Database RSS - composer - reviewed

CodeIgniter: Uploaded file extension validation bypass in `is_image` and `mime_in` rules

Fri, 07 Aug 2026 18:24:21 GMT

Impact

This is an unsafe file upload validation vulnerability that can lead to remote code execution in vulnerable application configurations.

Applications are impacted when they:

validate uploads using is_image or mime_in without an independent safe extension check, such as ext_in on patched versions
save uploaded files using the client-supplied filename
place uploads in a web-accessible directory where PHP files can execute

Patches

Upgrade to v4.7.4 or later.

Workarounds

Save uploads outside the public web root, preferably under writable/uploads.
Use $file->store() or $file->move($path, $file->getRandomName()) instead of preserving the original client filename.
Disable script execution in any public upload directory.
Manually verify the client filename extension before moving the file.
For image uploads, reject files when $file->getClientExtension() is not an allowed image extension.
For exact MIME-type validation, reject files when $file->getClientExtension() does not match $file->guessExtension().

References

CodeIgniter: Path traversal in UploadedFile::move() when using client-provided filenames

Fri, 07 Aug 2026 18:23:46 GMT

Impact

In affected versions, calling UploadedFile::move() without a second argument uses the client-provided filename without sanitization. Depending on the destination path and server configuration, an attacker can supply a filename containing path traversal sequences (e.g. ../../public/shell.php) to write uploaded content outside the intended upload directory.

The patch sanitizes this default (no-argument) path.

Note: The patch only sanitizes the filename when no second argument is passed. If your application explicitly passes a client-provided name as the second argument, you remain responsible for sanitizing it - the patch does not (and cannot) sanitize a caller-supplied filename:

// Unsafe - even after upgrading:
$file->move(WRITEPATH . 'uploads', $file->getName());
$file->move(WRITEPATH . 'uploads', $file->getClientName());

Patches

Upgrade to v4.7.4 or later.

Workarounds

If you cannot upgrade immediately, use a generated filename or sanitize the client filename before passing it to move().

Use a generated filename:

$file->move(WRITEPATH . 'uploads', $file->getRandomName());

Or sanitize the client filename before passing it to move():

helper('security');

$name = sanitize_filename($file->getClientName());
$file->move(WRITEPATH . 'uploads', $name);

References

CodeIgniter: SQL injection in Query Builder deleteBatch() when used with where() conditions

Fri, 07 Aug 2026 18:22:59 GMT

Impact

A SQL injection vulnerability exists in the Query Builder's deleteBatch() method. When deleteBatch() is used together with where() conditions, the bound values from the WHERE clause are substituted directly into the generated SQL with their escape flag ignored, so they are never escaped or quoted. If an application passes user-controlled input to where() before calling deleteBatch(), that input is interpreted as SQL rather than as a value, allowing SQL injection.

This affects only the deleteBatch() code path. Regular delete() operations escape where() binds correctly.

Patches

Upgrade to v4.7.4 or later.

Workarounds

If you cannot upgrade immediately:

Strictly validate and cast values (e.g. numeric IDs) before using them in conditions - though this does not fully protect string conditions.
Do not pass user-controlled input to where() when using deleteBatch().
For user-controlled conditions, use a normal delete() with Query Builder binds instead of deleteBatch().
Where possible, express required matching values through the batch data and onConstraint() rather than as separate user-controlled where() clauses.

References

CodeIgniter: Spoofable forwarded HTTPS headers in IncomingRequest::isSecure()

Fri, 07 Aug 2026 18:21:54 GMT

Impact

IncomingRequest::isSecure() trusted the X-Forwarded-Proto and Front-End-Https headers from any incoming request. In affected deployments, an attacker could spoof these headers and cause the application to incorrectly treat an HTTP request as secure.

This may impact applications that rely on isSecure(), force_https(), forceGlobalSecureRequests, or similar logic to enforce HTTPS-only access or make security-sensitive decisions.

Exploitability depends on deployment configuration. Applications are most exposed if the backend is reachable directly over HTTP, or if a reverse proxy/load balancer forwards client-supplied forwarding headers without stripping or overwriting them.

Patches

Upgrade to v4.7.4 or later.

Workarounds

Users who cannot upgrade immediately should enforce HTTP-to-HTTPS redirects outside CodeIgniter, for example with Apache .htaccess/virtual host rules, nginx server blocks, Caddy site config, or load balancer redirect rules.

Users should also ensure that reverse proxies strip or overwrite client-supplied X-Forwarded-Proto and Front-End-Https headers before forwarding requests to the application.

References

API Platform Core: Relation IRIs are not type-checked: a related resource can be denormalised as the wrong resource type (type confusion)

Fri, 07 Aug 2026 16:54:42 GMT

Summary

The API Platform serializer's AbstractItemNormalizer does not validate the resource type returned when resolving relation IRIs, allowing type confusion where a resource of an unintended type can be silently assigned to a relation property.

Impact

An attacker who can submit write requests (POST/PUT/PATCH) to an API Platform endpoint with writable relations can supply a relation IRI pointing to a resource of a different type than the relation's declared class. Because getResourceFromIri() does not pass an $operation to IriConverter::getResourceFromIri(), the is_a type guard at IriConverter.php:86 is skipped. For untyped relation properties (legacy @var-only style), the wrong-typed object is silently assigned, corrupting invariants and potentially feeding downstream logic that assumes the declared type (CWE-843). For typed properties (modern PHP 8.x), the substitution is blocked by Symfony's PropertyAccessor with an InvalidTypeException.

Affected versions

api-platform/core < 4.1.30
api-platform/core >= 4.2.0, < 4.2.26
api-platform/core >= 4.3.0, < 4.3.12

Older major series (2.x, 3.x) ship the same vulnerable code path and are end-of-life; no fix is planned.

Patched versions

4.1.30
4.2.26
4.3.12

Fix

An is_a guard is added inside AbstractItemNormalizer::getResourceFromIri() (and the equivalent inline call sites on 4.1) so that a mismatched IRI throws InvalidArgumentException, mirroring the operation-aware check the IriConverter already performs when an operation is supplied. This forces a 400 Bad Request response for cross-type IRIs instead of a silent assignment.

Workarounds

Declare a PHP type on every writable relation property (e.g. public ?Foo $relation = null; instead of @var Foo $relation). Symfony's PropertyAccessor will then reject a mismatched object with InvalidTypeException. This does not cover collections of mixed-type interfaces; upgrading to a patched version is the only complete fix.

Proof of concept

A functional test posts a Bar IRI to a Foo-declared relation on an untyped property. Without the fix the server responds with HTTP 201 and the Bar IRI appears in the response payload. With the fix the server responds with HTTP 400 (Invalid IRI "/bars/1").

Full PoC: tests/Functional/Security/TypeConfusionRelationIriTest.php in the patched branches.

References

src/Serializer/AbstractItemNormalizer.php — vulnerable relation IRI load
src/Symfony/Routing/IriConverter.php — conditional is_a guard (operation-aware path)

Credit

Reported by @alexandre-daubois.

References

Smarty Security stream restriction bypass through stream: resource

Fri, 07 Aug 2026 15:10:51 GMT

smarty/smarty version 5.8.0 can read local files through PHP stream wrappers even when Smarty Security is enabled and all streams are disabled with Security::$streams = null.

The bypass uses Smarty's built-in stream: resource type. A template such as:

{include file="stream:php://filter/read=convert.base64-encode/resource=/tmp/secret.tpl"}

is handled as Smarty resource type stream, so the security check that would normally reject the underlying php wrapper is not applied. StreamPlugin then opens the nested php://filter/... URI directly.

For comparison, the direct resource:

{include file="php://filter/read=convert.base64-encode/resource=/tmp/secret.tpl"}

is blocked with stream 'php' not allowed by security setting.

Affected package:

Ecosystem: Packagist / Composer
Package: smarty/smarty
Confirmed affected version: 5.8.0
Confirmed source reference from Composer lock: 78d259d3b971c59a0cd719c270cc5cbb740c36a7
Current stable version on Packagist at review time: v5.8.0
Packagist usage at review time: 41,113,855 total downloads and 840,604 monthly downloads

Relevant code paths:

Smarty\Resource\BasePlugin::load(...)
Smarty\Resource\StreamPlugin::getContent(...)
Smarty\Security::isTrustedStream(...)

BasePlugin::load() maps the built-in resource name stream directly to StreamPlugin before the code path that checks PHP stream wrappers with stream_get_wrappers() and Security::isTrustedStream($type). StreamPlugin::getContent() later calls fopen($filepath, 'r+') on the nested URI when the resource name contains ://.

Preconditions:

An application must render templates that are not fully trusted while relying on Smarty Security to restrict local files and PHP stream wrappers. The PoC sets:

$smarty->enableSecurity();
$smarty->security_policy->streams = null;

Local reproduction:

The PoC creates a disposable template directory and a separate outside directory. It enables Smarty Security, disables all streams, and then compares three includes:

../outside/secret.tpl to confirm the ordinary trusted-directory boundary is enforced.
php://filter/... to confirm direct PHP streams are blocked by Security::$streams = null.
stream:php://filter/... to show the built-in stream: resource bypasses the same restriction and reads the outside file.

Run:

php -d display_errors=1 poc.php

Observed sanitized output:

package=smarty/smarty
installed_version=v5.8.0
template_dir=<tmp>/templates
outside_template=<tmp>/outside/secret.tpl
plain_dotdot_include=BLOCKED:Smarty\Exception:Smarty Security: not trusted file path '<tmp>/outside/secret.tpl'
direct_php_filter_include=BLOCKED:Smarty\Exception:stream 'php' not allowed by security setting
stream_php_filter_include=OK:U01BUlRZX1NUUkVBTV9XUkFQUEVSX1NFQ1VSSVRZX0VTQ0FQRQ==
expected_base64=U01BUlRZX1NUUkVBTV9XUkFQUEVSX1NFQ1VSSVRZX0VTQ0FQRQ==

The plain_dotdot_include line shows the directory boundary is enforced for ordinary traversal. The direct_php_filter_include line shows the same policy rejects php://filter when used directly. The stream_php_filter_include line shows that wrapping the same URI in Smarty's stream: resource bypasses that restriction and reads the outside file.

Impact:

A template author can bypass Smarty Security stream restrictions and read local files that are readable by the PHP process. With php://filter, file contents can be base64 encoded and rendered back through the template. This bypasses both the intended Security::$streams = null restriction and the normal trusted-template-directory check that blocks ../ traversal.

Duplicate checks:

OSV query for Packagist/smarty/smarty version 5.8.0 returned no vulnerabilities.
GitHub advisory query for ecosystem=composer and affects=smarty/smarty returned historical Smarty advisories, including sandbox escapes, PHP code injection, XSS, and older path traversal issues. The listed path traversal advisories affect older versions and do not describe this current stream:php://filter resource-wrapper bypass in 5.8.0.
GitHub issue search in smarty-php/smarty for stream:php://filter returned zero results.
Public searches for Smarty StreamPlugin php://filter and smarty/smarty isTrustedStream stream: did not identify a clear public duplicate during triage.

Suggested remediation:

When resolving the built-in stream: resource, parse and validate the nested URI scheme before opening it. For example, stream:php://filter/... should call Security::isTrustedStream('php'), and Security::$streams = null should block the resource before StreamPlugin::getContent() reaches fopen().

It would also be safer for StreamPlugin to reject nested stream wrappers by default unless the underlying wrapper is explicitly allowed by the active security policy.

References

Smarty: Symlink path traversal out of trusted directories

Fri, 07 Aug 2026 15:02:39 GMT

When Smarty's Security policy is enabled, secure_dir (and the configured template/trusted directories) restrict which local files a template may read via {include} and {fetch}. The trust check in Security::_checkDir() resolved the requested path with Smarty::_realpath(), which normalizes the path as a string only and does not follow symbolic links. A symlink placed inside a trusted directory therefore passed the trust check, while the underlying file_get_contents() followed it to an arbitrary file outside the sandbox (e.g. /etc/passwd).

Impact

An attacker able to (a) cause a symlink to exist inside a trusted directory (e.g. a user-upload area located within the template path) and (b) cause a template to reference that path can read arbitrary files readable by the PHP process, escaping the secure_dir boundary. Confidentiality impact only.

Patches

Fixed in 5.8.2. Security::_checkDir() now resolves the requested file with native realpath() and re-validates the canonical, symlink-free path against the trusted directories (which are canonicalized the same way, so legitimate symlinked deployment paths such as a Capistrano current symlink or macOS /var → /private/var keep working). It falls back to string normalization only when the file does not yet exist on disk.

Workarounds

Ensure no untrusted symlinks can be created within any directory listed in secure_dir/the trusted template directories; restrict write access to those directories to trusted processes only.

References

Fix commit: 99c048c
CWE-22

References

Craft CMS: Passkey login accepts replayed WebAuthn assertions

Fri, 07 Aug 2026 14:57:29 GMT

Craft CMS passkey login accepts WebAuthn requestOptions from the unauthenticated login request body and does not persist the updated credential counter returned by the WebAuthn assertion validator. A captured passkey login request body can therefore be replayed because the old challenge is accepted again, and the stored credential counter remains stale.

Craft CMS 5.10.3 and current 5.x HEAD accept PublicKeyCredentialRequestOptions from the unauthenticated users/login-with-passkey request body and do not persist the updated PublicKeyCredentialSource returned/mutated by web-auth/webauthn-lib after assertion validation.

As a result, a captured passkey login request body is not one-time-use. Reposting the same requestOptions and response can result in validation against the same stale credential counter and create another Craft session for that user. This weakens passkeys from a fresh, server-challenged authentication ceremony into a replayable bearer artifact if one successful assertion body is exposed.

Attack Scenario

A victim successfully logs in with a passkey.
The POST /actions/users/login-with-passkey body containing requestOptions and response is captured from an application/request log, debugging proxy, browser extension, compromised analytics layer, or another request-body disclosure point.
The attacker reposts the same body to users/login-with-passkey.
Craft deserializes the attacker-supplied requestOptions, so the old challenge remains accepted for validation.
The WebAuthn validator compares the assertion's signCount against the stale stored credential counter.
Because Craft did not persist the updated credential source on the original login, the same stale stored counter is used again.
The same captured assertion validates and Craft creates another authenticated session for the victim account.

This is exactly what WebAuthn's challenge and signature-counter lifecycle is meant to prevent: a successful assertion should be bound to a server-issued challenge and should update server-side credential state so it cannot be used again.

Impact

An attacker who obtains one successful passkey login request body can replay it to create additional authenticated Craft sessions for that user. This defeats WebAuthn’s intended one-time challenge and signature-counter replay protection, reducing a passkey assertion to a reusable bearer artifact if exposed through request logging, a debugging proxy, a compromised same-origin script layer, or another request-body disclosure path.

The impact is an account/session takeover of the affected passkey account after a single assertion body is captured. The issue is in Craft’s native passkey login flow and affects fresh Craft installations with passkeys enabled.

References

Craft CMS: Arbitrary file read via SplFileObject in non-sandboxed template contexts

Thu, 06 Aug 2026 21:54:45 GMT

The create() Twig function (introduced in 5.9.0) allows instantiation of arbitrary PHP classes from template code, restricted only by a 5-entry blocklist. SplFileObject is not in the blocklist, enabling arbitrary file read, including .env (security key, DB credentials) and the passwd file from non-sandboxed Twig template contexts, such as entry type title formats and URI formats.

The sandbox correctly blocks create() in system email templates, so this finding applies only to admin-configured, non-sandboxed contexts that require allowAdminChanges=true.

Prerequisites

Admin access to the Craft control panel
allowAdminChanges must be true (default in dev/staging, recommended false in production)
Admin must be able to edit entry type settings (title format, URI format)
Any user who subsequently creates an entry in the affected section triggers the file read

Limitations

Requires admin-level access: not exploitable by low-privilege users
allowAdminChanges must be true: production best practices recommend false, which prevents entry type configuration changes
Per Craft’s own severity guidelines, findings requiring allowAdminChanges=true are rated low
The create() function is blocked by the Twig sandbox, so this cannot be exploited via system email templates or any other sandboxed context

Impact

An admin user (or an attacker who has compromised an admin account) can read arbitrary files from the server filesystem by setting a malicious entry type title format using create('SplFileObject', ['/path/to/file']). In production environments, this exposes .env files containing the CRAFT_SECURITY_KEY, database credentials, API keys, and other secrets. The file contents are rendered as entry titles visible to any user with permission to view entries in the affected section.

The impact is limited by the requirement for admin access and allowAdminChanges=true.

References

Craft CMS: Authenticated leak of secret environment variables

Thu, 06 Aug 2026 21:53:31 GMT

Environment variables and secrets are interpolated into a Twig template even when the Twig sandbox is enabled, allowing them to be leaked by an authenticated attacker.

The Craft vulnerability CVE-2026-31857 was only patched by applying sandboxed Twig templating. This theoretically protects Craft CMS against RCE attacks, provided the sandbox is enabled and secure, with no known bypasses.

However, the same request parameter elementId, which allows for sandboxed Twig templates to be rendered, also includes functionality that interpolates referenced environment variables. If the parameter includes a string of the form ${ENV_VAR} then the string is replaced with the environment variable or secret from a secrets file with that name.

Afterward, the string is rendered as a Twig template. If the sandbox is disabled, Twig templates can already gain RCE or access environment variables using the getenv function. Sandboxed Twig templates should not have this access, but now do thanks to this additional environment-variable replacement behavior.

The template’s resulting value is not directly reflected in the response. To exfiltrate the value, the sandboxed Twig template cannot use network functions. But it can use a blind error-based approach similar to blind SQL injection. With enough requests, any environment variable or secret can be incrementally leaked. This can be abused to forge a session, escalate privileges with the CRAFT_SECURITY_KEY, and steal credentials for the database, SMTP server, or other connected APIs or blob storage.

Impact

An authenticated attacker, with permission to access the control panel, can render a malicious Twig template and steal arbitrary environment variables and secrets with a large number of requests, even if the Twig sandbox is enabled through enableTwigSandbox().

References

Craft CMS:Authorization bypass: view-only Categories user can modify category structure via structures/move-element

Thu, 06 Aug 2026 21:43:54 GMT

A control-panel user who holds only the viewCategories permission for a category group (and not saveCategories) can permanently modify that group's category structure — reordering and re-parenting categories via the structures/move-element action.

A read-time authorization grant that a write endpoint later trusts. For categories, the structureEditable flag is computed from the view permission (src/elements/Category.php:205) instead of the save permission (entries correctly use saveEntries — src/elements/Entry.php:341). When the read-only category index renders, craft\base\Element::indexHtml() calls Craft::$app->getSession()->authorize('editStructure:<structureId>'); StructuresController then authorizes the structure-mutating action solely on that session grant, with no canSave re-check.

Verified on Craft CMS 5.10.5. Same class as the moderate-severity authorization bypasses fixed in 5.10.3 and 5.10.5; this is a distinct, unpatched instance.

Impact

A low-privileged, authenticated user (view-only on a category group) can persistently alter the sibling ordering and parent/child nesting of the category taxonomy. Because a category’s URI is derived from its position in the structure (ancestor slugs), moving a category changes its URL and the URLs of its descendants, and can corrupt any navigation/menus built from the category tree. This is an integrity/broken access-control issue: content that the user has no permission to modify is being modified. No confidentiality impact and no RCE; scope is content/taxonomy integrity.

References

Craft CMS: Missing authorization check allows non-admin control panel users access to user registration metrics

Thu, 06 Aug 2026 21:42:58 GMT

ChartsController::actionGetNewUsersData() at /actions/charts/get-new-users-data is missing a requirePermission('viewUsers') authorization check. Any authenticated control panel user, regardless of permissions beyond accessCp, can POST to this endpoint to receive time-series user registration counts for the entire site or for an arbitrary user group ID.

The viewUsers permission is consistently required throughout the control panel before exposing user-related data, but this action enforces only the base accessCp check inherited from the framework.

Each call returns the total count of users who joined the specified group in the requested period.

Impact

Any control panel user with only accessCp permission can obtain the total number of registered users and their registration date distribution across any time window.

In installations with multiple editor roles, this allows a low-privilege control panel user to infer user group sizes and registration trends that would normally require the viewUsers permission to access.

No user PII (name, email, password) is disclosed; only aggregate counts and timestamps are returned. Confidentiality impact is low. No integrity or availability impact.

References

Craft CMS: Incorrect path validation could potentially lead to path traversal

Thu, 06 Aug 2026 21:36:11 GMT

The ensurePathIsContained function of the Local file system class is theoretically vulnerable to path traversal, although no exploitable scenario has been discovered.

When a file is read, an Asset object uses the getFileStream method of the Volume where the asset file is stored, which in turn uses the getFileStream method of the file system class used by that Volume. For the Local file system, this function returns a stream to a file on the local disk after verifying and creating the correct file path.

The file path is constructed by first validating the path and then adding a prefix to the validated and normalized path. The prefix is the path to the local directory that houses the particular volume. The order of operations matters here: first, a validation step, afterward a normalization step, and finally the construction of the resulting file path. This opens the possibility of a desanitization-style vulnerability, where the normalization invalidates the assumptions made by the validation or sanitization that preceded it.

Impact

The issue is not directly exploitable, but for hardening, a fix is recommended regardless.

References

Craft CMS: Stored XSS in the control panel via unescaped draft name

Thu, 06 Aug 2026 21:33:15 GMT

The control-panel helper that renders element chip/card labels writes an element's draftName into the page without HTML-encoding it, while the surrounding path segments are encoded.

A low-privilege control-panel user who can create a draft of an element (for example, an entry) controls the draft name, so they can store an XSS payload that executes in the browser of any other control-panel user who is shown that element’s chip or card (element indexes with drafts visible, relation and element-selection fields that reference the element, and the drafts list).

This allows a low-privilege author to run JavaScript in an administrator’s authenticated session and take over the control panel. It is the same output-encoding class as the recently fixed GHSA-xrqc-p465-2xvg (Structure entry title) and GHSA-3x4w-mxpf-fhqq (revision context menu), which encoded other user-controlled titles but not the draft name.

Prerequisites

A control-panel account with permission to edit entries in at least one section and create drafts.
A higher-privileged user (for example, an administrator) who is later shown the draft’s chip or card (an element index with drafts visible, or a relation/element-selection field referencing the element).

Limitations

Requires the victim to be shown the affected element's chip/card in the control panel (normal day-to-day activity; element indexes and relation fields are routine).
The payload runs in the control-panel origin in the victim’s session.

Impact

A low-privilege author can run arbitrary JavaScript in the session of any higher-privileged control-panel user who is shown the element’s chip or card, including administrators. This is a cross-privilege stored XSS, not a self-XSS: the attacker and the victim are different users, and the payload fires during routine browsing of element indexes and relation fields.

Because the script runs in the victim’s control-panel origin, it can read the CSRF token that Craft embeds in the page JavaScript (Craft.csrfTokenValue, confirmed present on control-panel pages) and issue authenticated control-panel actions as the victim. This was verified end-to-end on Craft Pro: an in-session request to the users/save-user action created a brand new account (User saved., HTTP 200), an admin-only capability that an author can never perform directly.

References

PHP_CodeSniffer gitblame report command injection via crafted filename

Thu, 06 Aug 2026 21:31:34 GMT

Impact

PHP_CodeSniffer versions before v3.13.6 and v4.0.2 contain a command injection vulnerability in the code creating the Gitblame, Hgblame and Svnblame report(s).

As a result, running PHP_CodeSniffer over untrusted files, for example, in a CI pipeline that scans pull requests, or on a developer machine reviewing third-party code, could result in attacker-controlled shell commands being executed when the Gitblame, Hgblame or Svnblame report(s) would process a file whose name contains shell metacharacters.

Users using the default Full report, or any of the other non-*blame reports, are not affected.
Users on a runtime platform which does not allow filenames to contain shell metacharacters, such as " and ;, are not affected.

Patched versions

The issue has been fixed in PHP_CodeSniffer v3.13.6 and v4.0.2. We recommend all users upgrade to these versions at their earliest convenience.

Workaround

Users of PHP_CodeSniffer who cannot upgrade immediately should ensure they do not use the Gitblame, Hgblame or the Svnblame reports when scanning untrusted code.

This is especially relevant for CI jobs, pre-commit or review tooling, automated review services, and any service that scans untrusted repositories or uploaded source trees.

Credits

Many thanks to both @Faze-up and @edorian for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the PHP_CodeSniffer repository.

References

Craft CMS: Arbitrary user password reset leading to administrator account takeover

Thu, 06 Aug 2026 21:04:11 GMT

The vulnerability allows any authenticated user to change their own password without providing the current password or having an active elevated session. It also allows the attacker to change other users’ passwords if the attacker’s account has edit users permission (which doesn’t allow changing others’ passwords) and lacks Administrate users permission (which is required to change others’ passwords).

The vulnerability exists in the elements/save action when saving a User element. The UserPasswordValidator applies only a safe validator to the newPassword field without an on scenario restriction. This makes newPassword mass-assignable during the generic element save flow, completely bypassing the dedicated users/set-password action that enforces elevated session verification.

An attacker with any authenticated session (whether it’s hijacked or a normal / low-privileged user) can change their own password, and potentially take over administrator accounts.

Required Permissions

Access the control panel
Edit users (needed for the account takeover attack scenario)

Impact

Any authenticated user can change their own password without providing their current password.
Users with Edit users permission can change any user’s password, including administrators.

References

Craft CMS: Authenticated RCE through Twig sandbox escape

Thu, 06 Aug 2026 21:02:28 GMT

The Twig sandbox mechanism in Craft CMS is configured to allow dangerous functionality from the Yii framework, leading to authenticated RCE in a manner similar to previously disclosed vulnerabilities.

The Twig sandbox in Craft CMS works by implementing Twig's SecurityPolicyInterface. The resulting SecurityPolicy class implements the checkMethodAllowed and checkPropertyAllowed methods of the interface. The implementations compare whether the called method or property is in a configured allowlist or is marked with the AllowedInSandbox attribute.

Additionally, SecurityPolicy allows the allowlisting of whole classes, which is shorthand for allowing all methods and properties of that class to be called. Both the allowlists for tags, filters, variables, methods, properties, and classes, as well as the AllowedInSandbox attribute mechanism, are preconfigured by Craft CMS to allow user-defined templates to use core functionality unimpeded. Additionally, Craft CMS project developers can add more to the allowlists or mark their custom methods and so on as safe with AllowedInSandbox.

The SecurityPolicy class's allowlisting mechanism is potentially dangerous, as it allows all methods and properties on an object of the allowed class. This means that the checked object can be a subclass and be allowed. And it means that the allowed methods and properties can be defined on any class of the class hierarchy of the object, which does not have to be the allowed class itself.

Craft CMS uses the AllowedInSandbox attribute to mark the ElementInterface as safe. The Element class implements this interface and is the base class for many relevant model classes in Craft CMS, like Entry, User, Asset and so on. Additionally, Element extends the craft\base\Component class. Going up the class hierarchy of craft\base\Component, eventually the class yii\base\Component is reached, which is located in the Yii framework used by CraftCMS. yii\base\Component is known to contain a dangerous arbitrary function call gadget which leads to previously disclosed RCE vulnerabilities in Craft CMS (GHSA-255j-qw47-wjh5, GHSA-2fph-6v5w-89hh, GHSA-7jx7-3846-m7w7, GHSA-qrgm-p9w5-rrfw). Due to lax class allowlisting, this function-call gadget is allowed in the Twig sandbox. This allows sandboxed Twig templates to use known payloads based on the function-call gadget to achieve RCE.

Impact

An authenticated attacker with permission to access the control panel can render a malicious Twig template and gain RCE, even if the Twig sandbox is enabled through enableTwigSandbox().

References

Craft CMS: Missing authorization check allows non-admin control panel users to reorder Global Sets

Thu, 06 Aug 2026 20:55:48 GMT

The reorder-sets action in Craft CMS’s GlobalsController is missing the requireAdmin() check that the adjacent save-set and delete-set actions both enforce. Any authenticated control panel user can POST to /actions/globals/reorder-sets and permanently reorder all global sets in the project config, regardless of whether they have admin access. The reordering is written through to the project config and persists across requests.

Description

GlobalsController exposes three administrative actions for managing global set structure. Two of them gate on admin status; the third does not.

Prerequisites

A Craft CMS instance with at least two global sets and a non-admin control panel user account.

Impact

A non-admin control panel user can reorder all global sets. While this does not expose or modify content, reordering global sets modifies the project config -- a versioned artifact that is typically committed to source control and deployed across environments. An attacker can create noise in the project config history, trigger config-sync conflicts, or manipulate the display order seen by all editors in the admin panel. The same non-admin user cannot create or delete global sets because those actions correctly enforce requireAdmin().

References

Craft CMS: Authenticated RCE via `condition.config` JSON cleanse bypass

Thu, 06 Aug 2026 20:45:00 GMT

Craft CMS has an authenticated remote code execution issue in the control panel element-search condition handling.

Craft cleans the outer request-controlled condition array with Component::cleanseConfig(), but Conditions::createCondition() later decodes and merges the JSON string in condition.config without re-running cleanseConfig() on the decoded/merged 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. After JSON decoding, those keys reach FieldLayout object creation and are interpreted by Yii as behavior/event configuration.

The RCE is semi-blind: the trigger endpoint returns a normal JSON response, and the command output is verified via a server-side file-write side effect retrieved in a subsequent request.

Preconditions

The attacker needs an authenticated Craft control panel session.
A valid CSRF token is required.

Impact

An authenticated control panel user can inject Yii behavior/event configuration after Craft’s intended config cleanse boundary. In the confirmed local lab, this led to command execution as the PHP/web user.

Potential attacker impact:

Execute operating system commands as the PHP/web user.
Read Craft secrets, environment variables, and application configuration.
Access database credentials and stored site content.
Modify site content, users, and application state.
Pivot to internal services reachable from the Craft host or container.
Cause denial of service or establish persistence depending on deployment permissions.

References

league/commonmark: Denial of service via deeply nested XML output

Thu, 06 Aug 2026 20:42:54 GMT

Impact

XmlRenderer pretty-prints XML by emitting depth-proportional indentation whitespace for every opening and closing tag. For a tree of depth n, the indentation alone sums to O(n²) bytes of output (and corresponding memory), reachable through MarkdownToXmlConverter — e.g. str_repeat('> ', $depth) . "x\n", a single line of nested blockquotes — or through a direct XmlRenderer::renderDocument() call on an attacker-influenced AST.

This affects applications that convert untrusted Markdown to XML, which is an opt-in output path. The parser's max_nesting_level bounds the depth of parser-created trees, but its default is high enough to reach damaging sizes, can be raised by the host application, and does not constrain custom or programmatically built ASTs handed straight to the renderer. The result is a memory / output-size amplification rather than a hard crash, which is why this issue is rated Medium rather than High. No confidentiality or integrity impact. XML rendering was introduced in 2.0.0 (first shipped in 2.0.0-beta1, June 2021) and has emitted depth-proportional indentation ever since, so all 2.x releases are affected (verified against 2.8.x, clean upstream 1902f60f). 1.x has no XML renderer and is not affected.

Workarounds

Applications converting untrusted Markdown to XML should:

Lower max_nesting_level to a conservative value appropriate to expected content, so the parser refuses to build extremely deep trees. This is the most direct lever for parser-produced ASTs, but does not protect trees built programmatically and passed straight to XmlRenderer.
Cap input size before conversion, since the amplification is driven by input-proportional depth.
Constrain XML consumers with memory / output-size limits (and streaming or size caps on any downstream XML parser or storage) so one request cannot allocate unbounded output.
Prefer HTML rendering for untrusted content where XML is not strictly required — the HTML renderer does not emit depth-proportional indentation and is not subject to this amplification.

References

league/commonmark: Denial of service via colliding heading slugs

Thu, 06 Aug 2026 20:41:45 GMT

Impact

UniqueSlugNormalizer::normalize() makes each slug document-unique by searching for an unused numeric suffix, but restarts that search from 1 on every collision. The k-th heading that collapses to the same base slug performs k−1 array lookups, so K colliding slugs cost Σ(k−1) = O(K²). An attacker can force every heading onto a single base slug trivially — many empty ATX headings, identical heading text, or punctuation-only headings that normalize to the empty string.

The path is reached whenever the shared slug normalizer runs over attacker-controlled text. That happens when HeadingPermalinkExtension is registered (its HeadingPermalinkProcessor normalizes every heading), independently through FootnoteExtension (its AnonymousFootnoteRefParser normalizes every ^[label] reference), and on any TableOfContentsExtension site (which requires HeadingPermalinkExtension to be co-registered). The default slug_normalizer/unique setting (UniqueSlugNormalizerInterface::PER_DOCUMENT) accumulates collisions across the whole document. No authentication is required — a small document body turns into seconds of CPU and denies service. Availability impact only. UniqueSlugNormalizer was introduced in 2.0.0 (first shipped in 2.0.0-beta1, May 2021); the 1.x heading-permalink slug generator performed no de-duplication and is not affected. All 2.x releases (including 2.8.x) are affected.

Workarounds

Integrators who cannot upgrade immediately can:

Set slug_normalizer/unique to false / UniqueSlugNormalizerInterface::DISABLED, which stops the de-duplication scan entirely — at the cost of losing id uniqueness (colliding headings then share an anchor).
Disable HeadingPermalinkExtension (and TableOfContentsExtension, which depends on it), and FootnoteExtension where anonymous footnotes reach the same normalizer, for untrusted Markdown.
Cap the accepted document size / heading count upstream so K cannot reach the quadratic danger zone.

Each of these trades off functionality or correctness; upgrading to the patched release (which removes the quadratic behavior while keeping unique ids and identical output) is the recommended remediation.

References

league/commonmark: Denial of service via duplicate footnote definitions

Thu, 06 Aug 2026 20:40:53 GMT

Impact

The Footnote extension records one backref per footnote reference and then appends the entire backref list for every footnote definition block in the document, without ever de-duplicating or removing repeated definitions of the same label (GatherFootnotesListener, populated by NumberFootnotesListener). A document that references a single label N times and also supplies N duplicate [^a]: definitions of that label therefore produces N × N FootnoteBackref nodes, so output size, parse time, and peak memory are all O(N²).

Reaching the vulnerable path requires FootnoteExtension to be registered on the Environment. This is opt-in, but is a commonly enabled GFM-style feature; no other non-default configuration is required. An unauthenticated attacker can expand a ~10 KB request into a ~62 MB HTML response, ~3 s of CPU, and ~440 MB of peak memory — enough to OOM-kill a default 128 MB PHP worker and deny service. Availability impact only; no confidentiality or integrity effect. The Footnote extension was introduced in 1.5.0 (May 2020) with this backref logic present from the first commit, so all releases from 1.5.0 onward (including every 2.x through 2.8.x) are affected.

Workarounds

There is no library-level option to cap the number of footnotes, references, or definitions, so no configuration switch prevents the amplification. Integrators who cannot upgrade should:

Disable the Footnote extension for untrusted input, or
Enforce a strict input-size limit before conversion — but note this is a weak control here, since the ~10 KB payload that already triggers the 62 MB / ~440 MB blowup is well within typical request-body limits, so any cap must be aggressively small to help.

Upgrading to the patched release is the recommended remediation.

References

league/commonmark: Denial of service via adjacent inline attribute blocks

Thu, 06 Aug 2026 20:39:52 GMT

Impact

With the Attributes extension enabled, AttributesListener::findTargetAndDirection() resolves each attribute node's target by walking outward through its siblings. For a run of N adjacent inline attribute blocks placed at the start of a block (with nothing to their left), each node scans the entire sibling list to the far-right end before giving up and falling back to the parent. Each resolution is therefore Θ(N) and the whole run is Θ(N²).

Reaching the path requires AttributesExtension (opt-in, but first-party: League\CommonMark\Extension\Attributes\AttributesExtension). No other configuration matters — the quadratic walk runs unconditionally during parsing and is not gated by the attributes/allow allow-list, the on* hardening added in 2.7.0, or allow_unsafe_links. An unauthenticated attacker can submit a ~32 KB input ({#a} repeated 8,000 times) that takes over 5 seconds to convert, with time growing quadratically in input length — a cheap denial of service. Availability impact only. The Attributes extension was introduced in 1.5.0 (May 2020) with this outward-walk resolver present from the first commit, so all releases from 1.5.0 onward (including every 2.x) are affected.

Workarounds

There is no library-level configuration that gates the quadratic walk. Integrators who cannot upgrade can only reduce exposure indirectly:

Disable the Attributes extension for untrusted input, or
Impose a strict maximum input length before conversion — noting that because the cost is quadratic, even a modest cap must be small to meaningfully bound worst-case CPU.

Upgrading to a release containing the fix is recommended.

References

league/commonmark: Quadratic-time denial of service when parsing crafted Markdown

Thu, 06 Aug 2026 20:37:20 GMT

Impact

Affected versions of league/commonmark can have quadratic time complexity when parsing specially crafted Markdown lines. In practical terms, doubling the length of an affected line can make the parser perform roughly four times as much work. The parser identifies locations using character positions, but regular-expression matches report byte positions. These positions differ when a UTF-8 character uses more than one byte. Several parsing paths repeatedly rescan growing portions of the line to translate between the two positions. The Autolink extension can also copy and validate the remaining line at every URL-like prefix.

In current 2.x releases, a single non-ASCII character anywhere on a line can place that whole line on the slower multibyte path. An attacker can combine it with a long run of leading whitespace or repeated Markdown punctuation, causing increasingly large rescans. When the Autolink extension is enabled, repeated URL-like prefixes provide another trigger, even on ASCII-only lines. Each trigger fits within one long line, so complex Markdown structure is unnecessary.

An attacker who can submit Markdown for conversion can use a comparatively small request to consume disproportionate CPU time and allocation activity. Repeated or concurrent requests can occupy all available PHP workers and prevent legitimate requests from completing. The core paths affect CommonMarkConverter, GithubFlavoredMarkdownConverter, and custom environments. The autolink-specific path affects applications using AutolinkExtension or GithubFlavoredMarkdownExtension. Applications that process only trusted Markdown are not remotely exploitable. The impact is limited to availability: it does not disclose data, change rendered output, or bypass rendering restrictions. Settings such as html_input and allow_unsafe_links do not mitigate the issue because the expensive work occurs before rendering.

Patches

The issue is patched in 2.9.0 and later. Starting in that release, the parser records UTF-8 character-to-byte positions incrementally, converts ordered regular-expression match positions without restarting from the beginning of the line, and matches autolinks against the original line instead of copying every remaining suffix. The affected work then grows in direct proportion to the input size while preserving existing Markdown output and configuration behavior. Versions from 0.6.0 through 2.8.3 are affected. The 0.x and 1.x release lines are no longer supported, so their users must upgrade to 2.9.0 or later.

Workarounds

If you cannot upgrade immediately, reject or truncate inputs with excessively long individual lines before passing them to the converter. A total request-size limit is also useful, but a per-line limit is important because every demonstrated trigger fits on one line. Choose limits appropriate for the application and enforce them before Markdown parsing begins. Restricting conversion to trusted users, applying strict execution-time limits, rate-limiting requests, and limiting concurrent conversions can further reduce exposure, but these measures are not complete substitutes for upgrading.

Disabling AutolinkExtension and avoiding GithubFlavoredMarkdownExtension removes the autolink-specific trigger, but the core multibyte parsing paths remain reachable in the standard parser. Existing nesting, delimiter, raw-HTML, and unsafe-link configuration options do not eliminate all affected paths. Applications that must continue processing untrusted Markdown should therefore enforce input limits even when autolinking is disabled.

References

league/commonmark: AttributesExtension href/src unsafe-link filter bypass via embedded control bytes

Thu, 06 Aug 2026 20:30:39 GMT

Summary

The AttributesExtension's href/src unsafe-link filter (AttributesHelper::filterAttributes()) can be bypassed by embedding control bytes in a javascript: URL that browsers discard before parsing the scheme. Two variants:

Tab/newline inside the scheme — a literal ASCII TAB (0x09), CR (0x0D), or LF (0x0A), e.g. java<TAB>script:alert(1). Per the WHATWG URL Standard's "basic URL parser" step 3, browsers "remove all ASCII tab or newline from input".
Leading C0 controls — e.g. <0x01>javascript:alert(1). Per step 1 of the same algorithm, browsers remove any leading or trailing C0 control or space. (A leading space alone does not bypass, because parseAttributes() already trim()s the value; other C0 bytes are not trimmed.)

The filter is a literal anchored-prefix regex (RegexHelper::isLinkPotentiallyUnsafe() / REGEX_UNSAFE_PROTOCOL) that matches neither obfuscated form, so in both cases the browser still executes javascript:alert(1).

This is confirmed reproducible even with allow_unsafe_links => false set — i.e. even applications that have followed the library's own documented hardening guidance for untrusted input remain exploitable.

This is a sibling gap in the same defense that CVE-2025-46734 (GHSA-3527-qv2q-pfvx) fixed in v2.7.0 — that fix made href/src respect allow_unsafe_links, but did not normalize control bytes before checking, so these obfuscation techniques were never covered.

Vulnerability

Files:

src/Util/RegexHelper.php:69 (REGEX_UNSAFE_PROTOCOL), :239-242 (isLinkPotentiallyUnsafe())
src/Extension/Attributes/Util/AttributesHelper.php:149-179 (filterAttributes())

CWE: CWE-79 (Improper Neutralization of Input During Web Page Generation / XSS) — primary

CWE-692 (Incomplete Denylist to Cross-Site Scripting) — the anchored-prefix denylist in REGEX_UNSAFE_PROTOCOL is incomplete. This is a composite of CWE-184 and CWE-79, so it captures the full "incomplete denylist → XSS" chain on its own.
CWE-86 (Improper Neutralization of Invalid Characters in Identifiers in Web Pages) — the specific evasion technique: control bytes embedded within the URI scheme identifier, which the browser strips before resolving it.

Root Cause

// src/Util/RegexHelper.php
public const REGEX_UNSAFE_PROTOCOL = '/^(?:javascript|vbscript|file|data):/i';

public static function isLinkPotentiallyUnsafe(string $url): bool
{
    return \preg_match(self::REGEX_UNSAFE_PROTOCOL, $url) !== 0 && \preg_match(self::REGEX_SAFE_DATA_PROTOCOL, $url) === 0;
}

// src/Extension/Attributes/Util/AttributesHelper.php
foreach ($attributes as $name => $value) {
    $attrNameLower = \strtolower($name);
    if (! $allowUnsafeLinks && ($attrNameLower === 'href' || $attrNameLower === 'src') && \is_string($value) && RegexHelper::isLinkPotentiallyUnsafe($value)) {
        unset($attributes[$name]);
        continue;
    }
    ...

The Attributes extension's own quote-value grammar (PARTIAL_DOUBLEQUOTEDVALUE = '"[^"]*"') accepts any byte except " inside quotes, including raw tab/CR/LF and other C0 controls, and parseAttributes() only trim()s (leading/trailing, and only the default charlist " \t\n\r\0\x0B" — so a leading \x01 survives). Critically, the core Markdown link-destination path (LinkParserHelper → UrlEncoder::unescapeAndEncode()) percent-encodes every control byte before this same safety check ever runs — but the Attributes extension's href/src handling has no equivalent normalization step, so the raw control byte reaches both the check and the final HTML output (Xml::escape() only escapes & < > " ', not tab/CR/LF, since they're legal bytes inside an HTML attribute).

Attack Scenario

An application enables the (commonly-used) AttributesExtension and sets allow_unsafe_links => false — the project's own documented hardening step for untrusted input.
An attacker submits Markdown: [Click me](javascript:alert(0)){href="java<TAB>script:alert(document.cookie)"} (TAB is one literal 0x09 byte).
The library emits <a href="java<TAB>script:alert(document.cookie)">Click me</a> — isLinkPotentiallyUnsafe() doesn't match the tab-split scheme, so the filter takes no action.
A victim viewing/clicking the link has the browser strip the embedded TAB and execute javascript:alert(document.cookie) in the victim's session — stored XSS, cookie theft, account takeover potential.

Why the payload needs an unsafe core destination. Step 2 above deliberately uses [Click me](javascript:alert(0)) rather than a normal link. LinkRenderer overwrites attrs['href'] with the node's own URL unless that URL is itself judged unsafe — so [x](https://example.com){href="java<TAB>script:..."} renders the harmless href="https://example.com", and an empty destination [x](){href="..."} renders href="". The attacker therefore supplies a core destination that the filter does catch, which suppresses the overwrite and lets the attribute-supplied href reach the final tag. This is no obstacle in practice — the attacker writes the entire Markdown document.

Two related forms that are not exploitable, noted so the fix isn't over-scoped:

Attaching the attribute to a non-link block — hi {href="java<TAB>script:alert(1)"} — does bypass the filter and emits <p href="java<TAB>script:alert(1)">, but href on a <p> is inert: there is nothing to navigate. (An earlier draft of this report described this as a "simpler, unconditional variant" of the attack; it is a filter bypass, not an XSS.)
<img src> is unaffected, since ImageRenderer unconditionally overwrites src from the core URL regardless of the safety verdict.

Recommended Fix

Normalize inside RegexHelper::isLinkPotentiallyUnsafe() before testing, mirroring the WHATWG URL parser's own normalization. This covers both variants, fixes every call site at once (LinkRenderer, ImageRenderer, and any third-party callers), and needs no changes in the Attributes extension.

Affected Versions

>= 1.5.0, <= 2.8.3 - every release that ships the AttributesExtension. Verified by installing each version and rendering the payloads with allow_unsafe_links => false. The attribute-value grammar (PARTIAL_DOUBLEQUOTEDVALUE = '"[^"]*"') has accepted raw control bytes since the extension was introduced, and none of the intervening parser rewrites narrowed it.

Prior Related Advisories

GHSA-3527-qv2q-pfvx / CVE-2025-46734 fixed a different Attributes-extension XSS (unallowlisted on* handlers, href/src not respecting allow_unsafe_links at all) in v2.7.0. This issue bypasses the specific href/src protection that fix introduced (the control-byte normalization gap was not part of that fix) - but the obfuscated inputs also work on older versions.