GHSA-rm67-g9ch-vxff: Poweradmin Broken Access Control (IDOR): Any Vulnerability
HIGHGHSA-rm67-g9ch-vxff is a HIGH (CVSS 8.1) broken access control (idor): any vulnerability (CWE-284: Improper Access Control) affecting Poweradmin libraries in the Packagist ecosystem. The issue involves broken access control (idor): any zone owner can modify dns records in zones they do not own. Remediation is available by upgrading affected packages to version 3.9.11, 4.2.5, 4.3.4.
GHSA-rm67-g9ch-vxff at a Glance
Security Impact
CVSS: 8.1
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H).
How to Fix GHSA-rm67-g9ch-vxff
To remediate this vulnerability, upgrade all affected Poweradmin dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
Upgrade poweradmin/poweradmin to 3.9.11
Upgrade poweradmin/poweradmin to 4.2.5
Upgrade poweradmin/poweradmin to 4.3.4
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
inspect dependencies for poweradmin/poweradmin
How to Check if You Are Affected
To determine whether your application is affected by GHSA-rm67-g9ch-vxff, inspect your project dependencies for Poweradmin:
inspect dependencies for poweradmin/poweradmin
Analyze the terminal output to locate any version of Poweradmin in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 3.9.11), your application is affected.
Note: Verify declared build manifests and deployed runtime container environments.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-284: Improper Access Control, where the product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. In Poweradmin, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
GHSA-rm67-g9ch-vxff Affected Poweradmin Versions
3 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
poweradmin/poweradmin
|
Packagist |
≥ 3.0.0
< 3.9.11
|
3.9.11
|
|
poweradmin/poweradmin
|
Packagist |
≥ 4.0.0
< 4.2.5
|
4.2.5
|
|
poweradmin/poweradmin
|
Packagist |
≥ 4.3.0
< 4.3.4
|
4.3.4
|
References
Frequently Asked Questions
What is GHSA-rm67-g9ch-vxff?
Which Poweradmin versions are affected?
What version fixes GHSA-rm67-g9ch-vxff?
Is poweradmin/poweradmin affected?
What is the CVSS score of GHSA-rm67-g9ch-vxff?
What CWE is associated with GHSA-rm67-g9ch-vxff?
How can I check Packagist dependencies for GHSA-rm67-g9ch-vxff?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-rm67-g9ch-vxff",
"modified" : "2026-07-24T21:55:15Z",
"published" : "2026-07-24T21:55:15Z",
"aliases" : [ ],
"summary" : "Poweradmin: Broken access control (IDOR): any zone owner can modify DNS records in zones they do not own",
"details" : "## Affected software\n\n- Product: Poweradmin (web front-end for PowerDNS)\n- Version tested: master, commit 7f28c3a97 (also reachable in the 4.x release line — the record-edit code is the same)\n- Component: record editing (web UI)\n- Vulnerability type: Broken Access Control / Insecure Direct Object Reference\n\n## Severity\n\nAny 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.\n\n## Summary\n\nWhen 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.\n\nA 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.\n\n## Where the bug is\n\nThe core mistake is in `RecordManager::editRecord()` in `lib/Domain/Service/Dns/RecordManager.php`:\n\n```php\n// line 298 – ownership is checked against the zone id from the request\n$user_is_zone_owner = UserManager::verifyUserIsOwnerZoneId($this->db, $record['zid']);\n...\n// line 346 – but the update targets the record id from the request\n$this->backendProvider->editRecord(\n $record['rid'], $name, $record['type'], $content, $validatedTtl, $validatedPrio, $record['disabled']\n);\n```\n\n`$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.\n\nThe backend write has no zone scoping at all — `lib/Infrastructure/Service/SqlDnsBackendProvider.php` line 235:\n\n```php\n$stmt = $this->db->prepare(\n \"UPDATE $recordsTable SET name = ?, type = ?, content = ?, ttl = ?, prio = ?, disabled = ? WHERE id = ?\"\n);\n$stmt->execute([$name, $type, $content, $ttl, $prio, $disabled, $recordId]);\n```\n\nIt's `WHERE id = ?` on the record id and nothing else, so any record in the database is fair game.\n\nThe 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.\n\nThere are two request paths that reach this same sink:\n\n1. 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.\n2. Single-record save — `EditRecordController::saveRecord()` reads `$_POST['rid']` and forwards the whole `$_POST` (including the attacker-chosen `zid`) into `editRecord()`.\n\nFor 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.\n\n## Proof of concept\n\nSetup (two accounts, two zones):\n\n- `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.\n- `admin` — owns `victim.example`, which is zone/domain id 2. That zone contains the record `www.victim.example A 1.1.1.1` with record id 5.\n\nSteps:\n\n1. Log in as `attacker`. Confirm the access control is actually there: browse to `/zones/2/edit` (victim.example). You get \"You do not have permission to access this zone.\" Good — you genuinely can't edit that zone the normal way.\n\n2. Open your own zone's edit page, `/zones/3/edit`, and start a save (change any field and submit) with your intercepting proxy on. Catch the `POST /zones/3/edit` request. It already carries a valid CSRF `_token` and a valid `serial` for your zone, so don't touch those.\n\n3. Edit the record block in that request so it targets the victim's record while keeping your own zone id:\n\n```\nPOST /zones/3/edit HTTP/1.1\nHost: localhost:8080\nCookie: PHPSESSID=<your attacker session>\nContent-Type: application/x-www-form-urlencoded\n\n_token=<the valid token from step 2>&serial=<the valid serial from step 2>&commit=1\n&record[5][rid]=5&record[5][zid]=3\n&record[5][name]=pwned&record[5][type]=A&record[5][content]=6.6.6.6\n&record[5][ttl]=3600&record[5][prio]=0\n```\n\nThe important part: `record[5][rid]=5` is the victim's record (in zone 2), and `record[5][zid]=3` is your own zone (so the ownership check passes).\n\n4. Send it. You get HTTP 200.\n\n5. Check the result. Record 5, which lives in the admin's zone, is now overwritten:\n\n```\nsqlite> SELECT id, domain_id, name, type, content FROM records WHERE id = 5;\n5|2|pwned.attacker.example|A|6.6.6.6\n```\n\n<img width=\"3363\" height=\"1311\" alt=\"Screenshot 2026-07-06 162351\" src=\"https://github.com/user-attachments/assets/a2013e3b-0993-42ac-9402-7933e6d9331f\" />\n\n\nIt's still `domain_id = 2` (the victim's zone) but its content is now attacker-controlled. You changed a record in a zone you were explicitly denied access to in step 1.\n\nTwo practical notes if you're reproducing this:\n\n- The `serial` field is Poweradmin's optimistic-lock. It's checked against **your own** zone's current SOA serial and it bumps by one after every successful save, so grab a fresh one each time (the intercept-and-modify approach in step 2 handles this for you automatically).\n- Record ids are sequential integers, so in a real attack you'd just walk `rid = 1, 2, 3, …` to hit every record in every zone on the box.\n\n## Impact\n\nWith one owned zone, an attacker can rewrite `content`, `type`, `ttl` and the `disabled` flag of any record anywhere in the installation. Concretely that means:\n\n- Repointing or corrupting other customers' / other departments' DNS records (integrity).\n- Silently disabling records by setting `disabled = 1` (availability).\n- A clean, resolvable hijack (victim's name kept intact) when the attacker owns a parent/ancestor zone of the target name — `HostnameValidator::normalizeRecordName` leaves the name alone if it already ends in the attacker's zone suffix, which is exactly the case in delegated-subzone setups (attacker owns `example.com`, victim owns delegated `sub.example.com`).\n\nIn the plain sibling-zone case the edited record's name gets forced under the attacker's zone suffix, which still destroys the original record — so at minimum it's cross-zone record deletion, and at most it's full record hijack.\n\nThe attacker's own CSRF token and own zone serial satisfy every form-level check, so nothing about the request looks abnormal to the app.\n\n## Suggested fix\n\nStop trusting the `zid` in the request. In `RecordManager::editRecord()` (and the `EditRecordController` path), look the zone up from the record id on the server side and use that for both the ownership check and the hostname normalization — the same thing `deleteRecord()` already does:\n\n```php\n$details = $recordRepository->getRecordDetailsFromRecordId($record['rid']);\nif ($details === null) {\n // record doesn't exist – reject\n return false;\n}\n$realZid = $details['zid'];\n// use $realZid for verifyUserIsOwnerZoneId() and for zone-name normalization\n```\n\nReject the edit if the record doesn't exist, and never let the client decide which zone a record \"belongs\" to.\n\n## Disclosure\nCredit: Found by Saif Salah (https://saifsalah.github.io/)\nFound during a security review of Poweradmin.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "Packagist",
"name" : "poweradmin/poweradmin"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "3.0.0"
}, {
"fixed" : "3.9.11"
} ]
} ]
}, {
"package" : {
"ecosystem" : "Packagist",
"name" : "poweradmin/poweradmin"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "4.0.0"
}, {
"fixed" : "4.2.5"
} ]
} ]
}, {
"package" : {
"ecosystem" : "Packagist",
"name" : "poweradmin/poweradmin"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "4.3.0"
}, {
"fixed" : "4.3.4"
} ]
} ]
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/poweradmin/poweradmin/security/advisories/GHSA-rm67-g9ch-vxff"
}, {
"type" : "WEB",
"url" : "https://github.com/poweradmin/poweradmin/commit/12651facf49a6d9ebeb38f01e65f4aa5bfbc4da0"
}, {
"type" : "WEB",
"url" : "https://github.com/poweradmin/poweradmin/commit/88f443d0bde9812ff8d00c094882c8b8e7303c49"
}, {
"type" : "WEB",
"url" : "https://github.com/poweradmin/poweradmin/commit/e021067157491ea70b8e333dc3f6a1ddf7e8e746"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/poweradmin/poweradmin"
}, {
"type" : "WEB",
"url" : "https://github.com/poweradmin/poweradmin/releases/tag/v3.9.11"
}, {
"type" : "WEB",
"url" : "https://github.com/poweradmin/poweradmin/releases/tag/v4.2.5"
}, {
"type" : "WEB",
"url" : "https://github.com/poweradmin/poweradmin/releases/tag/v4.3.4"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-284", "CWE-639" ],
"severity" : "HIGH",
"github_reviewed" : true,
"github_reviewed_at" : "2026-07-24T21:55:15Z",
"nvd_published_at" : null
}
}