# E-Maj 5.0.1 closes a PostgreSQL superuser escalation path for extension administrators E-Maj's October 28 maintenance release fixes a privilege boundary failure: a role with emaj_adm privileges could acquire PostgreSQL superuser rights. Operators using the table-change logging and rollback extension should review role assignments and upgrade. E-Maj 5.0.1 patches an emaj_adm-to-superuser escalation flaw in a niche but security-sensitive PostgreSQL rollback extension. - Status: Active - Published: 2026-10-31T21:58:53+13:00 - Updated: 2026-10-31T21:58:53+13:00 - Categories: Cloud & Infrastructure, Databases & Storage - Tags: database extensions, E-Maj, PostgreSQL, privilege escalation, security - Canonical HTML: https://beyondthe.news/dossiers/e-maj-5-0-1-emaj-adm-postgresql-superuser-escalation-fix ## What changed E-Maj 5.0.1, dated October 28, 2026 in the project's changelog and listed as stable on PGXN on October 29, fixes a vulnerability allowing a PostgreSQL role with emaj_adm privileges to acquire superuser rights. The maintainer says the fix changes ownership of the emaj schema and all its contents to the emaj_adm role. The release also corrects error handling in the emajParallelRollback.pl client when PREPARE TRANSACTION fails. E-Maj provides trigger-based logging and rollback of changes to selected PostgreSQL tables and supports PostgreSQL 14–19 in its 5.0 line. ## Why it matters PostgreSQL superuser rights bypass ordinary database permission boundaries. An extension administrator is often entrusted with audit and rollback functions, but should not thereby gain control of the whole database cluster. The E-Maj flaw is consequential precisely because it crosses that role boundary. The affected audience is narrow: operators who have installed E-Maj and granted emaj_adm privileges, especially in multi-user or delegated administration environments. The public changelog gives the prerequisite and remediation but does not document exploitation in the wild or a complete version-by-version exposure matrix. ## The privilege boundary that failed The official 5.0.1 change log states that a role holding emaj_adm privileges could obtain PostgreSQL superuser rights. That is not an unauthenticated internet-wide flaw: the role must already possess extension administration privileges. Nonetheless, those privileges can be delegated to people or service accounts that should not control the PostgreSQL cluster. The patch makes the emaj schema and its contents owned by emaj_adm, addressing the unsafe ownership boundary described by the maintainer. ## Where E-Maj is used E-Maj records INSERT, UPDATE, DELETE and related table changes with triggers, allowing operators to inspect, replay or roll back groups of tables to marked states. It is used in testing and in production batch or recovery workflows. The 5.0 release added PostgreSQL 19 support and non-superuser installation options, increasing the importance of checking who holds administrative privileges; the sources do not establish exactly when the escalation flaw first appeared. ## Upgrade and verification Operators should identify E-Maj installations, confirm the extension version and review memberships or grants involving emaj_adm. Plan the 5.0.1 upgrade using the project's supported extension installation and upgrade documentation, test rollback operations and check schema ownership afterwards. Avoid assuming that revoking an ordinary application role fixes the extension itself. The parallel rollback error-handling change is operationally useful but separate from the privilege escalation. ## Key details - E-Maj 5.0.1 changelog dated 28 October 2026; PGXN stable package listed 29 October. - The maintainer explicitly describes emaj_adm privilege holders acquiring PostgreSQL superuser rights. - Patch changes ownership of the emaj schema and its content to emaj_adm. - E-Maj supports logging, replay and rollback of changes to selected PostgreSQL table groups. - 5.0 series supports PostgreSQL 14–19; 5.0.0 introduced non-superuser installation capabilities. - Parallel rollback PREPARE TRANSACTION error handling is also fixed. - No public exploitation evidence or CVE identifier was established in the checked sources. ## Builder takeaways - Check whether any PostgreSQL databases have the E-Maj extension installed and which version is deployed. - Review who holds emaj_adm privileges, including service accounts and delegated operators. - Upgrade affected E-Maj deployments to 5.0.1 using the documented extension upgrade procedure, with a database backup and a rollback test. - Verify the emaj schema's ownership and confirm E-Maj operations still work after upgrading. - Do not equate this with a remote unauthenticated exploit; the published prerequisite is existing emaj_adm privilege. ## What to watch - Maintainer follow-up specifying affected earlier versions and any CVE or CVSS assignment. - Downstream packaging and deployment advisories. - Further audit of delegated extension-role permissions and upgrade compatibility. ## Uncertainties - The public changelog does not provide a complete affected-version matrix or proof-of-concept details. - No independently confirmed exploitation or compromised deployments were identified. - The full exploit mechanism beyond the disclosed ownership and privilege boundary has not been independently reproduced. ## Sources - [E-Maj 5.0.1 changes](https://pgxn.org/dist/e-maj/5.0.1/CHANGES.html) — E-Maj maintainers via PGXN · primary_release_notes · 2026-10-28T00:00:00+13:00. Direct maintainer statement of escalation condition, ownership fix and rollback-client correction. - [E-Maj 5.0.1 package](https://www.pgxn.org/dist/e-maj/5.0.1/) — PostgreSQL Extension Network · primary_package_registry · 2026-10-29T00:00:00+13:00. Stable package metadata, extension purpose and distribution. - [E-Maj source repository](https://github.com/dalibo/emaj) — Dalibo · primary_source_repository. Project code, documentation and version history.