Validate numeric region ownership in AbstractAddress::getRegionId()

[in-session]

Background

The underlying getRegionId() behavior predates the recent Magento security updates.

We started seeing the resulting inconsistent address state block checkout after applying the July 2026 Magento security hardening associated with APSB26-73.

One relevant change in that update moves the validateQuoteAddress plugin from the REST-specific DI scope:

vendor/magento/module-quote/etc/webapi_rest/di.xml

to the global quote DI scope:

vendor/magento/module-quote/etc/di.xml

Previously:

<type name="Magento\Quote\Model\Quote">
    <plugin name="validateQuoteAddress" type="Magento\Quote\Plugin\QuoteAddress" />
</type>

was registered only for REST requests.

After the security update, the plugin is registered globally for:

Magento\Quote\Model\Quote

so quote address validation is applied to additional PHP and checkout flows that call setShippingAddress() or setBillingAddress(), not only REST-specific flows.

This security change does not create the invalid region_id, and Magento\Quote\Plugin\QuoteAddress itself is not responsible for validating whether a region belongs to a country.

The inconsistent state can already exist before validation:

country_id = NL
region_id  = null
region     = "80"

and AbstractAddress::getRegionId() can then materialize the country-mismatched ID:

country_id = NL
region_id  = 80
region     = "80"

Persisted data observed

We also found already persisted addresses where region_id belonged to a different country than the address itself.

The following query can be used to identify these records in quote addresses:

SELECT
    qa.address_id,
    qa.quote_id,
    qa.address_type,
    qa.country_id,
    qa.region_id,
    qa.region,
    dcr.country_id AS region_country_id,
    dcr.code,
    dcr.default_name,
    qa.updated_at
FROM quote_address AS qa
INNER JOIN directory_country_region AS dcr
    ON dcr.region_id = qa.region_id
WHERE qa.region_id IS NOT NULL
  AND qa.country_id IS NOT NULL
  AND qa.country_id <> dcr.country_id
ORDER BY qa.updated_at DESC;

In our database this returned, among others, combinations such as:

address country   region_id   actual region country
AT                80          DE
NL                80          DE
LU                80          DE

Region ID 80 is:

DE / BAW / Baden-Württemberg

The same inconsistency was also present in saved customer addresses:

SELECT
    cae.entity_id,
    cae.country_id,
    cae.region_id,
    cae.region,
    dcr.country_id AS region_country_id,
    dcr.code,
    dcr.default_name,
    cae.updated_at
FROM customer_address_entity AS cae
INNER JOIN directory_country_region AS dcr
    ON dcr.region_id = cae.region_id
WHERE cae.region_id IS NOT NULL
  AND cae.country_id IS NOT NULL
  AND cae.country_id <> dcr.country_id
ORDER BY cae.updated_at DESC;

Historical mismatched customer address records were present as far back as 2024 and 2025.

This provides database-level evidence that invalid country/region combinations existed before the July 2026 security hardening.

The mismatch is ultimately rejected later by Magento address validation during quote/order validation.

In our case this became visible as:

Invalid value "80" for field regionId.

The relevant sequence is therefore:

numeric region value
→ AbstractAddress::getRegionId() can materialize a country-mismatched region_id
→ inconsistent address state can be persisted
→ hardened checkout/quote flow reaches address validation
→ country/region mismatch is rejected
→ checkout fails

Therefore the security hardening should be considered the point at which the existing data-integrity issue became visible in our checkout, not the origin of the invalid state.

[m2-assistant]

Hi @in-session. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[in-session]

@magento run all tests

[in-session]

@magento run all tests

[in-session]

@magento run Functional Tests CE

[in-session]

@engcom-Hotel
The reported test failures appear to be unrelated to the changes introduced in this pull request