GHSA-rm67-g9ch-vxff

Poweradmin: Broken access control (IDOR): any zone owner can modify DNS records in zones they do not own

Published

2026-07-24

Modified

2026-07-24

Sources

github-advisory

Summary

## Affected software - Product: Poweradmin (web front-end for PowerDNS) - Version tested: master, commit 7f28c3a97 (also reachable in the 4.x release line — the record-edit code is the same) - Component: record editing (web UI) - Vulnerability type: Broken Access Control / Insecure Direct Object Reference ## Severity Any authenticated user who owns at least one zone can tamper with records in every other zone on the server. In a shared/multi-tenant Poweradmin install this is effectively a cross-tenant DNS takeover. ## Summary When you save a record edit, Poweradmin checks whether you're allowed to touch the record by looking at a zone id you send in the POST body, but it then applies the change to a record id you also send in the POST body. Nothing checks that the record id actually belongs to that zone id. So you point the permission check at a zone you legitimately own, point the record id at somebody else's record, and the update goes through. A low-privilege "Editor" who only owns `attacker.example` was able to overwrite a record living in `victim.example` (owned by the admin), even though the same account gets a flat "you do not have permission to access this zone" if it tries to open that zone directly. ## Where the bug is The core mistake is in `RecordManager::editRecord()` in `lib/Domain/Service/Dns/RecordManager.php`: ```php // line 298 – ownership is checked against the zone id from the request $user_is_zone_owner = UserManager::verifyUserIsOwnerZoneId($this->db, $record['zid']); ... // line 346 – but the update targets the record id from the request $this->backendProvider->editRecord( $record['rid'], $name, $record['type'], $content, $validatedTtl, $validatedPrio, $record['disabled'] ); ``` `$record['zid']` and `$record['rid']` are both taken straight from the submitted form. The permission gate uses one, the write uses the other, and they're never tied together. The backend write has no zone scoping at all — `lib/Infrastructure/Service/SqlDnsBackendProvider.php` line 235: ```php $stmt = $this->db->prepare( "UPDATE $recordsTable SET name = ?, type = ?, content = ?, ttl = ?, prio = ?, disabled = ? WHERE id = ?" ); $stmt->execute([$name, $type, $content, $ttl, $prio, $disabled, $recordId]); ``` It's `WHERE id = ?` on the record id and nothing else, so any record in the database is fair game. The validation layer doesn't save it either. `DnsRecordValidationService::validateRecord()` (`lib/Domain/Service/DnsRecordValidationService.php`, around line 97) uses the zone id only to look up the zone name for hostname validation. It never verifies the record id lives in that zone. There are two request paths that reach this same sink: 1. Multi-record save — `EditController::saveRecords()` (`lib/Application/Controller/EditController.php`, ~line 571) loops over `$_POST['record']` and hands each entry's `rid`/`zid` to `editRecord()` verbatim. The controller's `run()` only permission-checks the zone id in the URL (~line 204), not the zone id inside each record row. 2. Single-record save — `EditRecordController::saveRecord()` reads `$_POST['rid']` and forwards the whole `$_POST` (including the attacker-chosen `zid`) into `editRecord()`. For comparison, the delete path does it correctly. `DeleteRecordController` (~line 101) derives the zone id from the record id on the server side with `getZoneIdFromRecordId()` and checks permission against that. `EditCommentController` also uses the URL zone id for both the check and the write. So this really is an oversight in the edit path, not a deliberate design choice — the safe pattern already exists elsewhere in the same codebase. ## Proof of concept Setup (two accounts, two zones): - `attacker` — a normal user on the "Editor" permission template (`zone_content_edit_own_as_client`, i.e. can only edit records in zones it owns). Owns `attacker.example`, which is zone/domain id 3. - `admin` — owns `victim.example`, which is zone/domain id 2. That zone contains the re

Affected packages

Remediation: Upgrade to 3.9.11 or later.

References

• https://github.com/advisories/GHSA-rm67-g9ch-vxff