Drupal core-recommended pins vulnerable symfony/polyfill-intl-idn version affected by CVE-2026-46644

Affects 11.x and main also - no composer update possible without changing the composer.json

Confirming this also affects 11.3.10 (latest stable). Any attempt to require symfony/polyfill-intl-idn:^1.38.1 is rejected because drupal/core-recommended 11.3.10 pins ~v1.37.0. For anyone needing an immediate workaround while waiting for the next core release, this works:

1. In composer.json, replace "drupal/core-recommended": "~11.3.1" by "drupal/core": "~11.3.1" (11.3 is my need, adapt it)
2. Add "symfony/polyfill-intl-idn": "^1.38.1" to the root requires.
3. Run composer update drupal/core symfony/polyfill-intl-idn -W

Moving this to main for now.

Because Symfony doesn't release all components (no release if no code changed), this can result in some components that haven't been updated in a while, suddenly getting a security release with a minor bump. It feels like this could potentially happen more and more.

I ran composer require "symfony/polyfill-intl-idn:1.38.1 as 1.37.0" for the workaround, which I'll have to remove manually again when Drupal core has a new release, I'm just wondering if this does happen more and more. Hopefully not, but I worry about it with more AI-found security releases in older dependencies or things that haven't been updated in a while and those maintainers not being able to release patch versions.

MR against main https://git.drupalcode.org/project/drupal/-/merge_requests/15879 is passing.

I also tested cherry-picking to 11.x, 11.4.x, 11.3.x, and 10.6.x, and it seemed to work fine.

I wanted to spin up a new Drupal install and got the same issue

PKSA-dwsq-ppd2-mb1x is blocking it. https://symfony.com/blog/cve-2026-46644-insecure-equivalence-in-symfony-...

Enabling the native `intl` extension on your infrastructure will successfully bypass the vulnerable polyfill code at runtime as polyfill checks for it first.

Placing the following as a temporary work around worked for me, including within a DDEV project using the ddev-drupal-contrib add-on:

  "require-dev": {
    "symfony/polyfill-intl-idn": "1.38.1 as 1.37.0"
  }

Does this mean that anyone hoping to update for SA-CORE-2026-004 is going run into a hurdle for the time being?

You can disable composer security block temporarily using either an ENV or command line option: https://getcomposer.org/doc/03-cli.md#composer-no-blocking

Alternatively, you can add entries to config.policy.advisories in composer.json: https://getcomposer.org/doc/06-config.md#block

Hid https://git.drupalcode.org/project/drupal/-/merge_requests/15877 because the tests weren't passing and it was targeted against 10.6.x.

You can also add this to config section of composer.json

"audit": {
    "ignore": ["PKSA-dwsq-ppd2-mb1x"]
}

Tested the MR plus cherry-picks to all the branches mentioned in #10.

composer install and composer audit lead to the desired result.

#7 worked for me. Thank you!

Given the timing of this with the recent Drupal core security release, should the community expect an immediate follow-up release, or will that arrive during the next scheduled security window?

Related Symfony issue: https://github.com/symfony/polyfill/issues/621

Opened https://github.com/symfony/polyfill/issues/621 upstream. Even if it's only us that ran into this problem, still feels unnecessary.

Committed/pushed to main, 11.x, 11.4.x, 11.3.x, 11.2.x, 10.6.x and 10.5.x, thanks!

Please issue a new release as many will not know exactly what is happening and may end up being confused about what is the best approach to use.

Going to add the two workarounds to the summary. Basically, if your workflow is hard-blocked on this issue (which is likely not exploitable in core), best to use one of the workarounds until a new core release is tagged. However. if you're not hard-blocked in your workflow, you can evaluate the CVE itself, potentially ignore your security scanner output, and choose to just wait for the next core patch release.

Bumping to critical retroactively on account of the fact that this is interfering with the Drupal CMS installer.

Adding missing quote at the end of composer require "symfony/polyfill-intl-idn:1.38.1 as 1.37.0" workaround in Issue Summary.

Will deleting the line and updating to Drupal core (10.6.10?) take care of reverting it, when the time comes? I tried deleting the line in composer.json, and running composer update --lock but it did nothing.

There are also security updates for symfony/routing and symfony/http-foundation.

When do you plan the release of the fixed Drupal version? We would like to update Drupal and symfony at once...

twig need update too ..
| Package | twig/twig |
| Severity | |
| Advisory ID | PKSA-fbvq-z33h-r2np |
| CVE | CVE-2026-48808 |
| Title | Sandbox property allowlist bypass via the `column` filter under |
| | `SourcePolicyInterface` |
| URL | https://symfony.com/blog/cve-2026-48808-sandbox-property-allowlist-bypas... |
| | e-column-filter-under-sourcepolicyinterface |
| Affected versions | >=1.0.0,<2.0.0|>=2.0.0,<3.0.0|>=3.0.0,<3.27.0 |
| Reported at | 2026-05-27T15:00:00+00:00

It's already fixed in dev.

The problem is also on the Drupal 11.3.x branch and by launching
composer require drupal/core-recommended:11.3.10 drupal/core-composer-scaffold:11.3.10 drupal/core-project-message:11.3.10 --update-with-all-dependencies

the result is this:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires drupal/core-recommended 11.3.10 -> satisfiable by drupal/core-recommended[11.3.10].
    - drupal/core-recommended 11.3.10 requires symfony/polyfill-intl-idn ~v1.37.0 -> found symfony/polyfill-intl-idn[v1.37.0] but these were not loaded, because they are affected by security advisories ("PKSA-dwsq-ppd2-mb1x"). Go to https://packagist.org/security-advisories/ to find advisory details. To ignore the advisories, add them to the audit "ignore" config. To turn the feature off entirely, you can set "block-insecure" to false in your "audit" config.

I reiterate: it's fixed in dev.

Hi. Im updating to 10.6.9.
I tried #7 fix with no luck.
Are you saying I need to update to 11.3 dev?

- drupal/core-recommended 10.6.8 requires drupal/core 10.6.8 -> found drupal/core[10.6.8] but these were not loaded, because they are affected by security advisories ("SA-CORE-2026-004"). Go to https://packagist.org/security-advisories/ to find advisory details. To ignore the advisories, add them to the audit "ignore" config. To turn the feature off entirely, you can set "block-insecure" to false in your "audit" config.

The command below worked after security updates were released yesterday, and you could easily update and get the latest versions of these components:

$ composer update symfony/http-foundation symfony/routing

These recent update commands were rejected, and you needed to use a workaround, like composer require "COMPONENT": "v3.2 as v3.1":

$ composer update twig/twig
$ composer update symfony/polyfill-intl-idn

Relax constraints for twig/twig and symfony/polyfill-intl-idn?

Would it be possible to relax constraints for components such as twig/twig and symfony/polyfill-intl-idn, as they are for symfony/http-foundation and symfony/routing? This would ease the burden on Drupal site owners and maintainers, allowing them to more easily keep their installations updated and safe.

This seems to be what Symfony maintainers recommend. @stof:

I would consider that an issue on the Drupal side.

The symfony/polyfill-* packages are maintaining a single 1.x branch (whether a new release bumps the minor or patch version depends on which changes are included in it). We never maintain older minor versions. So the only way to have a range that can accept the latest security release is to use a semver operator. Using the ~ operator pinning a specific minor version will not work.
Even if we were not skipping minor version releases in unmodified subtree packages (i.e. restoring the previous behavior of the release tooling), the kind of pinning done in drupal/core-recommended currently would not guarantee that you can get the security patch (as you could be pinning an older minor version that never receives the security patch).

From 1.37.1 release of symfony/polyfill for CVE-2026-46644 #621.

See also Change default Security Advisory behavior to allow secure updates #12883.

@ressa

sites can switch to drupal/core from drupal/core-recommended.

However for Twig especially, no it is not easy to relax the constraints in core-recommended, because Twig minor releases break core about as often as they release security releases, in last week's case at the same time. See the TwigNodeTrans change in https://git.drupalcode.org/project/drupal/-/commit/dc3c97a4d019548b3e227...

If people update Twig and break their production site, that is not necessarily better than a low severity security issue for a couple of extra days.

> It's already fixed in dev.

If its stable then make it stable, don't leave it in dev. Release a new core version or use a different technique.

Not everyone can "just use a dev[opment]" version.

If drupal/core-recommended must always track the drupal/core version, then do something else: a four digit version, using -p (patch) suffixes, ala https://packagist.org/packages/magento/community-edition. Get creative.

@catch: Thanks for clarifying the different constraints for components so fast, it's really great. With all the moving parts, it's a circle that's hard to square, and I very much appreciate all the efforts by the Drupal core maintainers.

@dpi I'm literally in the middle of committing the 6 MRs from #3592421: Update Symfony routing and http-foundation versions which are necessary to tag a new stable core release that won't have composer warnings, because the Symfony/Twig team decided to release multiple different security releases spread out over several days, too close to do a Drupal release for each one, but also not on the same day where a single Drupal release would have been perceived as 'fast'.

And your comment is not helping that happen any faster.

@ressa we might have to relax the constraints for the polyfills, that's actively under discussion and a bit different to Twig, although also exploring whether we can drop them: #3592119: Require the php intl extension and drop the symfony polyfill dependency

#49 needless to say everyones effort is appreciated. Its a less than ideal situation for everyone.

Thanks for making us aware #3592421: Update Symfony routing and http-foundation versions is being progressed!

I only want to be aware of a timeline, not where something is put into dev and then (the hypothetical) we'll get to it whenever we like it. Some of us aren't hyper focused on core dev.

I only want to be aware of a timeline ...

The policy is documented at Drupal core release schedule.

Short version: we aim to have a predictable release cycle, with a patch release once a month (first Wednesday) and up to one security release a month (third Wednesday).

We occasionally vary from that schedule, and in the current environment we are likely to vary more frequently. In the near to medium term, I will be surprised if there is a release more than once a week.

I understand there are rules for when to release a Drupal.
However, installing the patch for

Drupal core - Highly critical - SQL injection - SA-CORE-2026-004

From the day after the release, it is very difficult to apply without doing manual work, and therefore the versions:
11.3.10
11.2.23
11.1.10
10.6.9
10.5.10

will probably not be applied while waiting for a fix for this one.

Thankfully the update is now available.

I wasn't personally stuck, but kudos to the core folk for getting a release out!

Great work by all those involved in getting this out. 👏

Great news, #3600889: Remove some minor constraints from core-recommended is almost ready, so that updates like this one will not be blocked.