Caution: This documentation is for eZ Publish legacy, from version 3.x to 5.x.
For 5.x documentation covering Platform see eZ Documentation Center, for difference between legacy and Platform see 5.x Architecture overview.


This part of the 4.x documentation is for eZ Publish 4.0, only reference section is common for all eZ Publish 4.x versions as well as eZ Publish 5.x "LegacyStack", please select the version you are using for the most up to date documentation!

From 3.8, the standard packages are not included in the eZ Publish distribution itself. They are distributed separately as ".ezpkg" files. The files can be downloaded automatically by the setup wizard from the remote repository or manually from packages download page.

A package is a collection of items grouped together and stored in the specific format for the purpose of easy installation and removal. The system makes it possible to create packages and export them to ".ezpkg" files. This is the common way of how the packages are distributed. When an ".ezpkg" file is imported, it will become available under the system repository part of the eZ Publish installation. Most of the packages can be installed and uninstalled. The following table reveals the complete list of package operations that can are supported in the administration interface.



Create new package

It is possible to export your class definitions, content objects, settings, design styles etc. by creating new packages of different types. The newly created packages will be stored under the "Local" system repository.

Import new package

To import a new package, you need to select the desired ".ezpkg" file locally. The system will then upload the file, unpack it and place the resulting package under an appropriate internal repository within the installation.

Remove selected

You can remove packages from the system repository. Please note that the package itself will not be removed. Only the package files will be removed from the internal repository.


It is possible to install packages that are located under internal repositories. When you install a package, the system will create content classes and content objects, apply the settings specified in it and so on. (Please note that installing site packages and design packages is not supported.)

Export to file

A package located under the system repository can be exported to ".ezpkg" file. The system will ask you where to store the newly created file.


When you uninstall a package, all the changes made during its installation will be reverted.

Remote repository

Packages from remote repository can be downloaded by the setup wizard during the system installation process. However, the administration interface is unable to download packages from this repository.

The system will use the eZ Systems packages repository as the default remote repository. If you wish to use another remote repository, you need to specify its corresponding address using the "RemotePackagesIndexURL" configuration setting located in the "[RepositorySettings]" section of the "settings/override/package.ini.append.php" file.

System / internal repository

The default behavior is that all packages are stored in the "var/storage/packages" directory. This directory is the main system repository and its sub-directories are called "system repositories" or "internal repositories". The name of a sub-directory also functions as the actual name of a repository. The packages are sorted by their vendor. For example, the packages downloaded from will be stored under the "ez_systems" internal repository (var/storage/packages/ez_systems). Packages that have no vendor and packages created locally will reside under the "Local" repository (var/storage/packages/local).

It is possible to choose another location of the main system repository inside the "var/storage" directory. The following example shows how to change "settings/override/package.ini.append.php" in order to force the system to use "var/storage/importedpackages" as the main system repository:


Executable packages warning

This issue affects installations using eZ Publish Legacy, either stand-alone, or as part of eZ Platform 5.x, or in eZ Platform 1.11 and newer using LegacyBridge. If you are not using Legacy in any way, you are not affected.

The package system, by design, allows you to package an extension into a file, and export/import such packages. Extensions can of course contain PHP scripts, and they usually do. Such scripts can be used in an attack on the server. This problem is fundamental and cannot be fixed by any other means than by removing the feature.

By default, only the Administrator has the permissions to use the package system. It follows that the Administrator role, and any others granted packaging permissions, can only be held by users who already have access to the server, and/or can be trusted not to exploit this access.

As a consequence eZ Publish legacy should not be used in the type of shared hosting installation where Administrators are not supposed to have access to the underlying operating system, or to other eZ Publish installations on the same server. The package system is an old part of eZ Publish legacy, and it was not designed for that kind of installation. Currently this is not considered best practice anyway - setups using e.g. Docker and allow you to completely separate installations from each other. This is a better way to keep things secure than relying on PHP scripts being read-only even for administrators. (The package system does not exist in eZ Platform and will not be added there, since extensions are not used there.)

In summary:

If you are responsible for legacy installations where administrators cannot be fully trusted not to exploit their privileges, make sure to properly lock down the package system and/or fully separate web sites from each other.
 Make sure that the administrator password(s) are secure, and not using the default administrator password.

Proposed quick solution for those affected:

If you are administrating a shared hosting solution of this kind, it may take a while to change the setup. Meanwhile, one quick way to lock down the package system is to use rewrite rules to block all access to package URLs. Apache example:

RewriteRule ^/package/.* - [R=403,L]

or with URL-based SiteAccess:

RewriteRule ^/my_site_access/package/.* - [R=403,L]

or supporting both cases, and multiple SiteAccesses:

RewriteRule ^(/my_site_access|/my_site_access_admin)?/package/.* - [R=403,L]

This can be placed before other rules.

To be absolutely certain you can also (or instead of this) delete the /kernel/package directory in the eZ Publish web root. Please note that this will break the legacy installation wizard, since it relies on the package system to install the demo design.

Once the situation is resolved these measures should be reversed, to bring back the package features. You may want to do a review of whether the issue may have been exploited on your server(s).

Svitlana Shatokhina (16/06/2006 3:28 pm)

Dominika Kurek (27/02/2018 7:52 am)

Balazs Halasy, Julia Shymova, Geir Arne Waaler, Ricardo Correia, Dominika Kurek


  • change a package

    I have created a package. How can I change this package? How can I add or remove some files to/from an existing package?
    • Re: change a package

      You can't, you need to import it somewhere and do the changes on that installation and then export it when you are done.
  • ezpm.php script

    For package operations that take too long and result in a web page timeout, use the ezpm.php command line script, available in the root dir of eZ Publish