What changed: Country and Region service operations now enforce the virtual instance (company) scope during permission checks.

Why: Previously a user holding the MANAGE_COUNTRIES permission on one virtual instance could modify or delete countries and regions belonging to other instances through crafted API requests. The permission was validated but the record's scope was not.

Who is affected: Multi-instance deployments where non-Omniadmin users hold country and region management permissions.

How to update: Apply the patched release. After the upgrade these operations are limited to the user's own instance. Any process that relied on cross-instance country or region changes must be reworked to run per-instance, or under an Omniadmin context.

What changed: The Commerce Measurement Unit service now validates the instance (company) scope of the targeted record before allowing an update.

Why: An administrator on a secondary virtual instance could edit Measurement Units on the default instance by altering the measurement unit ID in the request. This is an Insecure Direct Object Reference.

Who is affected: Multi-instance Commerce deployments.

How to update: Apply the patched release. Cross-instance Measurement Unit edits are no longer possible, so confirm that any automation operates within the correct instance.

What changed: The payload sent to remote tax calculation providers now carries the correct currency code.

Why: The payload previously contained an incorrect currencyCode. Remote providers could calculate tax against the wrong currency.

Who is affected: Commerce customers using remote or external tax calculation integrations.

How to update: Apply the patched release and re-verify tax results with your provider.

What changed: Commerce Shipment operations — editing carrier/tracking details, deleting shipments, and adding/removing products or adjusting stock — now verify the instance scope of the shipment before acting. Why: An administrator on one virtual instance could edit or delete shipments, and manipulate their products and stock, on another instance by changing the shipment ID in the request — multiple cross-instance IDORs (LSV-1639). Who is affected: Multi-instance Commerce deployments. How to update: Apply the patched release; shipment operations are now restricted to the user's own instance.

What changed: Commerce Shipment operations now verify the instance scope of the shipment before acting. This covers editing carrier and tracking details, deleting shipments, adding or removing products, and adjusting stock.

Why: An administrator on one virtual instance could edit or delete shipments on another instance, and manipulate their products and stock, by changing the shipment ID in the request. These were multiple cross-instance Insecure Direct Object References.

Who is affected: Multi-instance Commerce deployments.

How to update: Apply the patched release. Shipment operations are now restricted to the user's own instance.

What changed: Order note edit operations now verify the permission scope of the requesting user against the specific note before allowing an edit.

Why: An Order Administrator role with restricted access to private notes could change the note ID parameter to edit the private notes of another administrator. This exposed content that should have stayed restricted. This is a Broken Access Control issue.

Who is affected: Commerce deployments that use restricted Order Administrator roles together with private order notes.

How to update: Apply the patched release. Private notes can no longer be edited by roles without explicit permission, whatever note ID is used in the request.

What changed: Order note operations now validate that the target order and note belong to the virtual instance of the requesting user. This covers adding, editing, deleting, and listing notes.

Why: A user on one virtual instance could add, edit, delete, or list order notes belonging to another instance by referencing the order or note ID directly. This is an Insecure Direct Object Reference.

Who is affected: Multi-instance Commerce deployments.

How to update: Apply the patched release. Order note operations across instances are now blocked.

What changed: Subscription operations now validate that the targeted subscription entry belongs to the virtual instance of the requesting user. This covers viewing, editing, and deleting subscription entries.

Why: An authenticated user with elevated privileges could view, edit, or delete PayPal subscriptions belonging to another virtual instance by referencing the subscription entry ID directly. This is an Insecure Direct Object Reference.

Who is affected: Multi-instance Commerce deployments that use PayPal subscriptions.

How to update: Apply the patched release. Subscription operations across instances are now blocked.

FinderColumn's constructor swaps the last flag for caseSensitive and replaces shouldBind(Object) with bindValue(QueryPos, Object); the BasePersistenceFinder, UniquePersistenceFinder, and CollectionPersistenceFinder constructors each gain a required String where parameter.

Why:

To reduce Service Builder generated code, these signatures changed so case-insensitive binding and custom <finder where="..."> clauses are handled in the shared base finder classes, letting more finders delegate to common code instead of generating their own.

Who this affects:

Update custom code that instantiates these classes or calls shouldBind. This is a framework-level change with little impact on typical Service Builder consumers.

cacheResult(List<T>) and cacheResult(T) moved into the BasePersistence interface, so implementations not extending BasePersistenceImpl must now implement them.

Why:

To reduce Service Builder generated code, the identical cacheResult logic was folded up into the base class so it no longer has to be regenerated in every per-entity *PersistenceImpl.

Who this affects:

Only custom persistence implementations that bypass BasePersistenceImpl need migration.

What:

The fetchLatestKaleoDefinitionVersion(long, String, OrderByComparator) method was removed from KaleoDefinitionVersionLocalService and its generated Util and Wrapper classes. Every caller passed null for the comparator, so switch to the remaining 2-arg overload.

Why:

To reduce Service Builder generated code, the unused 3-arg overload was dropped since every caller passed null for the comparator, eliminating dead generated code.

Who this affects:

Low impact unless you call this workflow API directly.

What:

the BasePersistenceFinder, CollectionPersistenceFinder, and FilterCollectionPersistenceFinder constructors gained a required String dbWhere parameter (inserted after where).

Why:

Native filterFind/filterCount SQL must use database column names, so finders whose where clause references a reserved-word column (e.g., Layout.system → system_) no longer generate invalid SQL.

Who this affects:

Code instantiating these finder classes directly. Pass the database-column form of the where suffix as the new dbWhere argument.

What:

saveOrUpdate(Object) was removed from the Session interface and its SessionWrapper, SessionImpl, and RecordingSessionWrapper.

Why: Hibernate 7 drops the method and its event SPI, so removing it now keeps the upcoming upgrade branch clean.

Who this affects:

Any code calling saveOrUpdate on the kernel ORM Session is affected. Delete the call for entities already loaded in the session (dirty-check flush handles it), use session.save(entity) for transient entities, or entity = (T)session.merge(entity) for detached ones.

What: setProjection(Projection, boolean useColumnAlias) was removed; the one-arg setProjection(Projection) behaves like the old useColumnAlias=true path.

Why: Liferay no longer supports Sybase, and no caller in the portal source tree passes false to the overload, so the branch and the corresponding API surface are unreachable.

Who this affects:

Callers that passed false. Drop the boolean to use the one-arg form, or hand-build a ProjectionFactoryUtil.sqlProjection(...) if you genuinely need the alias-free SQL.

What:

getSqlFragment(Object) on FinderColumn and ArrayableFinderColumn, plus buildSQLWhere(String, Object[]) on BasePersistenceFinder, each gained a boolean sqlQuery parameter.

Why:

The fragment must be emitted as native SQL or HQL/JPQL depending on the query path.

Who this affects:

Custom code that calls these persistence internals. Add the sqlQuery argument to your calls.

What:

propsUtil was added to the default restricted-variables list for FreeMarker and Velocity, blocking its use in restricted contexts like Web Content templates.

Why:

It exposed portal configuration (including sensitive data such as DB credentials) to template authors.

Who this affects:

Authors of restricted templates/ADTs that reference propsUtil or portletConfig. Register a GLOBAL TemplateContextContributor to expose specific properties, pass values via contextObjects/getCustomContextObjects(), or remove propsUtil from the restricted list in System Settings > Template Engines if you accept the exposure.

What changed: The System Settings → Upgrades → Database Migration Schema Export configuration is removed. The corresponding .config file trigger (DBMigrationSchemaExportConfiguration) is also removed.

Why: The export trigger moved to a dedicated UI inside of Server Administration.

Who is affected: Anyone triggering database schema export from System Settings or .config file.

How to adopt: Trigger the export from Server Administration → Database Migration, or use the new Headless Admin Server REST API /o/admin-server/v1.0/database-schema-export

The behavior of Marketplace Fragments in GET, POST, and PUT operations has changed: the HTML, CSS, JavaScript, and Configuration fields for Marketplace-sourced fragments are now returned as null, regardless of their stored content. Additionally, LAR exports no longer include Marketplace fragments. Teams that relied on the previous behavior of reading or exporting Marketplace fragment code via API or LAR must update their integrations accordingly. This change was introduced to enforce licensing boundaries and prevent unauthorized redistribution of Marketplace content. Any import payload that contains Marketplace fragment data is processed as-is — no transformation is applied, and errors resulting from that data are the caller's responsibility.

A long-standing validation rule that blocked pages whose Friendly URL matched their numerical Layout ID from being successfully imported has been resolved. Previously, exporting a page with a Friendly URL set to its own Layout ID and importing it into a site where a page had the same Layout ID would throw a LayoutFriendlyURLException and fail silently. This fix changes the import validation logic to allow such Friendly URLs when the Layout ID context matches. Teams with existing import/export automation that worked around this error should review their scripts, as the workaround may no longer be needed.

Priority compaction behavior for page experiences has been standardized: gaps between experience priority values are now compacted consistently across all ADD, UPDATE, and DELETE operations. Previously, adding a new experience did not compact priorities, which could leave numerical gaps (e.g., priorities 0, 1, 4 instead of 0, 1, 2). Now the ADD operation also compacts priorities to maintain a contiguous sequence. Any integration or automation that reads or sets experience priority values by absolute number — rather than by relative order — may see those values shift after this change and should be updated to rely on ordering rather than specific priority integers.