New Business Rule on User Table in Yokohama Patch 5

[Tim Deniston]

A new business rule was inserted on the sys_user table with Yokohama Patch 5. The BR is called "Prevent invalid country code" and has a sys_id of 3b638e8338596210f8773223ad5a62dd. This is causing an issue with updating users all of a sudden. If a user has an invalid Country value, all of a sudden no updates can occur on the user until this is corrected. This may be a problem for anyone who has LDAP or Azure AD pushing Country values that don't exactly conform to what ServiceNow is expecting. The Country field has historically been a string field with choices that have inconsistent values (US and USA and United States, for example). Starting with Yokohama Patch 5, these apparently need to all be corrected. 

The Yokohama Patch 5 release notes do not mention this new BR but it's sure having a big impact. 

[evanschwenk]

Not sure if anyone else is trying to solve this problem, but I noticed that it's only querying 'iso3166_2' which is ISO Short. As we're syncing via AAD, our codes are coming in as 'USA', which doesn't match United States of America's ISO Short of 'US'. 

It does, however, match the ISO Long value, which is mapped to 'iso3166_3'. 

Not sure why they didn't include both Short and Long ISO, but we've corrected the issue by adding a OR condition to the query, and this fixed the problem for us.

[Tim Deniston]

ServiceNow finally announced the CVE: KB2344042 and KB2264930

CVE is here: CVE-2025-3089 

Per the KB above, the versions where this is fixed are...

Release	Fixed Version
Washington	Washington DC Patch 10 Hot Fix 2a (released April 2025)
Xanadu	Xanadu Patch 7a (released April 2025) Xanadu Patch 8 (released April 2025)
Yokohama	Yokohama Patch 1a (released April 2025)  Yokohama Patch 2  (released April 2025)
Zurich	Zurich (EA) (released July 2025)

I still can't see the original problem record PRB1841312, but I'm guessing we know enough about the issue now. 

[FilipVacula]

Thank you for sharing, Tim. It is helpful to have all the resources handy and be able to share them with the customer.

In our case, this caused the User Provisioning from Entra ID to fail. I went down the rabbit hole of identifying a good solution, as it initially seemed that Entra ID does not have a reliable source of Country Code in ISO3166 format. My main consideration was to use the core_country table to match Country Name and map it to its ISO code. However, this would not work reliably because the Name would have to be stored exactly the same way in Entra ID as in ServiceNow, which cannot be guaranteed.

This led me back to integration basics - the format of the exchanged data must be known and agreed upon beforehand, especially when the domain of values is already standardised - countries. The proper solution then is for Entra ID to send the country code in the ISO3166 format. After reiterating on this, we found an attribute which matches this criteria and this ultimately solved our challenge.

Seeing that the Business Rules are fixing a security vulnerability, I recommend not deactivating, and for future upgrades not even modifying them.

[Rolf Nyhus]

In our case the sys_user.country field is a reference to "core_country", thus I'm adding condition to check against sys_id

[BorisR112699856]

Thanks all for the good insights. This broke our User provisioning process.
I received the announcements but there were ZERO details in it that this business rule will get introduced and have such an impact.

Are we 100% sure that this is related to the mentioned CVE? How do you know?