Pantheon release notes

Moving forward, all Pantheon sites must be owned by a Professional Workspace. My Dashboard is not going away, but sites currently owned by an individual account must be moved. You can move your sites yourself now, before Pantheon begins migrating remaining sites in January 2027.

What you need to do

1. From My Dashboard, go to Sites and select the sites you want to transfer.
2. Select Move to workspace.
3. Choose the destination Professional Workspace and confirm the move.

The migration starts immediately, and you can move multiple sites at once. The migration will not affect your site's uptime or other site functionality; the primary change is where it appears in the Pantheon Dashboard.

Important

Self-service migration supports only unpaid Professional Workspaces. To move a site to a paid Professional Workspace, contact Pantheon Support.

Unpaid sites moved into an unpaid Professional Workspace will be subject to Pantheon's 30-day trial beginning in January 2027. Existing customers with active paid workspaces are not affected. Learn more about the 30-day trial.

If you don't take action

Starting in January 2027, Pantheon will automatically migrate sites still in My Dashboard into a system-generated Professional Workspace. Pantheon will notify you at least 30 days before migrating any of your sites.

The migration will not affect your site's uptime or other site functionality, but Pantheon will choose the destination workspace and its organization for you.

The latest security update for Next.js addresses three vulnerabilities in upstream dependencies: two critical vulnerabilities and one high-severity vulnerability.

Action required

Because this is a security update, we recommend that customers update affected Next.js applications as soon as possible. Customers are responsible for updating their application dependencies and redeploying; Pantheon does not update Next.js sites on customers' behalf.

The published Next.js advisory lists 16.4.1 and 15.5.28 as patched versions.

If your application directly manages React Server Components packages, update them to the patched versions listed in the React advisories: 19.0.9, 19.1.10, 19.2.9, or 19.3.1, as applicable.

Highlights

This update addresses three upstream security vulnerabilities:

• Critical — Remote code execution in image processing: A vulnerability in the upstream image-processing stack can lead to remote code execution when Next.js processes SVG files on glibc-based Linux systems. The advisory identifies Next.js 15.5.28 and 16.4.1 as patched versions. As a workaround, use Sharp 0.35.5 or later. See GHSA-2464-fhr4-w9xw.
• Critical — React Flight remote code execution: Crafted React Server Component payloads can lead to remote code execution in rare cases involving multiple typed arrays and attacker-controlled values. See GHSA-xqc2-xf4c-x3h3.
• High — Denial of service through Server Functions: Crafted requests to Server Function endpoints can cause excessive CPU use or out-of-memory exceptions. Applications that do not use server-side React or a framework that supports React Server Components are not affected. See GHSA-h3gv-c5rc-p453.

For full technical details and affected package versions, review the linked security advisories.

Pantheon is continuing the phased migration of Advanced Global CDN (AGCDN) to our next-generation edge platform. Starting October 15, 2026, AGCDN customers who use rate limiting or geolocation, and whose current configuration is fully supported in Phase 2, are eligible to migrate. Pantheon will contact eligible customers directly.

What's included

Phase 2 adds two features that you configure yourself in a pantheon-edge.yml file at the root of your site's code repository. Each site environment uses its own settings, and changes go live when you push and deploy your code. Changes no longer require a request to Pantheon.

• Rate limiting: Limit how many requests a single client, identified by IP address or JA4 fingerprint, can make to a site environment, using one of four pre-defined tiers.
• Geolocation: Send the visitor's approximate location, such as country, region, and city, to your site in a single Pantheon-Geo request header.

Before you migrate

• If your site reads AGCDN geolocation headers, update your code to read the Pantheon-Geo header. The header name, format, and available fields are different from AGCDN.
• Rate limiting uses pre-defined tiers. Custom request thresholds and time windows, including 1-second windows, aren't available.
• At launch, pantheon-edge.yml is supported for sites that push code to their Pantheon Git repository. Support for sites that use GitHub, GitLab, or Bitbucket integration, and for Next.js sites, is coming later.

How migration works

This migration is not self-serve. Pantheon's Professional Services team will:

1. Review your current Legacy AGCDN configuration and confirm feature support with current capabilities on NextGen.
2. Migrate your supported rules and configuration.
3. Make the migrated configuration available for you to review.
4. Coordinate the DNS cutover with you during an agreed change window.
5. Validate the configuration after cutover.

Action required

If you are eligible for Phase 2, you will receive an email. Respond to the ticket to confirm your technical contact so we can schedule your migration.

AGCDN customers who are not contacted for Phase 1 or Phase 2 don't need to do anything at this time, and will be contacted at a later date.

Learn how to configure rate limiting and geolocation in the Advanced Edge documentation. Learn more about our switch to Next-generation GCDN with bot protection in this related blog post.

Drupal core security release SA-CORE-2026-014 (CVE-2026-108097, risk 19/25) is now available. It fixes a critical remote code execution vulnerability in the Field UI module. Drupal core alone is not directly exploitable, but several exploit paths exist through contributed modules, and at least one does not require authentication. Custom code can also expose the vulnerable functionality.

Action required

Update your Drupal sites to a patched release as soon as possible.

• Drupal 11.4.10
• Drupal 11.3.19
• Drupal 10.6.19

Drupal 12.0.0-alpha1 through 12.0.0-beta1 are also affected. See the security advisory for Drupal 12 fix details.

Drupal 11.2.x and earlier, Drupal 10.5.x and earlier, Drupal 9, and Drupal 8.9 are end-of-life. They are affected and do not receive a patch. Upgrade these sites to a supported release.

Drupal 7 sites on Pantheon receive this fix through Drupal 7 long-term support. See the Drupal 7.107 release note.

To apply the update, use one-click core updates in the Pantheon dashboard.

Mitigation until you update

If you cannot update right away, uninstall the core Field UI module (field_ui). The Drupal Security Team states this protects your site until you update.

As a founding Platform Partner of the Drupal Steward program, Pantheon provides protection against some known attack vectors. Steward does not cover all possible exploits, so update your site.

As part of Pantheon's Long-Term Support (LTS) for Drupal 7, Drupal 7.107 is now available with a backported security patch.

This release backports the fix for SA-CORE-2026-014 (CVE-2026-108097), a critical remote code execution vulnerability in the Field UI module. Drupal core alone is not directly exploitable, but several exploit paths exist through contributed modules, and at least one does not require authentication.

Action required

Apply the latest upstream update to your Drupal 7 site to receive this fix. See related documentation for how to apply core updates.

This fix changes how Field UI overview tables assign rows to regions: Drupal core no longer calls the #region_callback function set on a table row. After you update, review whether any custom code uses #region_callback, and test the Manage fields and Manage display pages to confirm the Field UI tables work as expected.

About Drupal 7 long-term support

Pantheon has partnered with Tag1 Consulting to deliver security updates and maintenance for Drupal 7 sites. This extended support is included at no additional cost.

For configuration guidance and detailed information, visit our related documentation.

Pantheon has updated the default PHP version for the Drupal (Composer Managed) upstream to PHP 8.3, replacing the previous default of PHP 8.2.

New Drupal sites created from Pantheon's upstreams use PHP 8.3. Existing sites that do not set php_version in their own pantheon.yml move to PHP 8.3 when they apply this upstream update. When you apply the update, Pantheon also updates config.platform.php in your composer.json to match, if it does not already.

Sites started from the Drupal 11 start state will see this update, but should already be running PHP 8.3.

Action required

Test the update before you deploy it to the Live environment. Apply it in Dev or a Multidev environment, confirm your modules and theme work on PHP 8.3, then promote it.

If your Drupal 10 site needs to stay on PHP 8.2, pin the version by setting php_version: 8.2 in your site's pantheon.yml before you apply the update. For steps, see Manage PHP Versions.

If you maintain a custom upstream, this change is not reflected in your pantheon.upstream.yml unless you update your fork from Pantheon's upstream.

The latest security release for WordPress, 7.1.3, is available on Pantheon.

Action required

Because this is a security update, we recommend all users upgrade to WordPress 7.1.3 as soon as possible from your Pantheon dashboard or Terminus to access the latest features, fixes, and security enhancements. See related documentation for how to apply core updates.

Pantheon has deployed a platform-wide mitigation (virtual patching via our routing network) against external abuse of the stored XSS on the Comments administration page, and is actively monitoring that rule. However, customers need to update their sites as soon as possible.

Highlights

This release resolves seven security vulnerabilities:

• A stored XSS on the Comments administration page, exploitable via pending comments.
• A DoS issue in the WP_Http::make_absolute_url() method.
• A second-order SQL injection in WordPress WXR export.
• A weakness allowing Author role users to sticky posts.
• Unauthenticated disclosure of comments on private and unpublished posts.
• Imgur embeds are vulnerable to XSS.
• Forgeable parameters passed to the {status}_{type} hook can lead to action name collision.

For full details, see the WordPress 7.1.3 release notes and WordPress documentation.

The 1.34.0 update is now available for the WordPress (composer managed) upstream. This update changes the default PHP version to 8.3, syncs the upstream with Roots Bedrock, and fixes a PHP warning. The Bedrock sync changes the Composer repository defaults, which can cause merge conflicts in your composer.json file.

Updates

• Updates the default PHP version to 8.3 and changes the PHP requirement in composer.json to >=8.3. For more information about the PHP default change, see New default PHP version 8.3 for WordPress upstreams. (For more information see #204.)
• Syncs the upstream with Bedrock. (For more information see #201.) This includes:
  • Changing the Composer repository from WPackagist (wpackagist.org) to WP Packages (repo.wp-packages.org). Package names for plugins and themes change from wpackagist-plugin/* and wpackagist-theme/* to wp-plugin/* and wp-theme/*.
  • Removing the roots/wp-password-bcrypt package from composer.json.
  • Setting WP_ENVIRONMENT_TYPE from WP_ENV when it is not already defined, and setting WP_DEVELOPMENT_MODE when it is configured.
  • Setting MYSQL_CLIENT_FLAGS to use SSL when DB_SSL is set.

Bug fixes

• Resolves a rtrim() warning in PHP 8.1 and later environments. (For more information see #189. Props @mattmacneil.)

For more details, refer to the WordPress (Composer Managed) changelog.

Action required

To benefit from these updates and ensure your site is using the most current version, apply the update to your WordPress (composer managed) site or custom upstream.

If your composer.json file requires plugins or themes using wpackagist-plugin/* or wpackagist-theme/* package names, or has custom entries in repositories, applying this update can cause merge conflicts in that file. When you resolve the conflicts, keep your custom requirements and update the package names to the new wp-plugin/* and wp-theme/* names, or keep the WPackagist repository entry.

For assistance with managing merge conflicts, refer to our documentation on auto-resolving via the dashboard or manually resolving via the command line.