vulnerability / NVI-00001852 / Revision 1
Poweradmin: Broken access control (IDOR): any zone owner can modify DNS records in zones they do not own
OSV carries this publisher advisory for poweradmin/poweradmin, poweradmin/poweradmin, poweradmin/poweradmin. This is an aggregated source copy; consult the original publisher and compare update dates.
This report has not inspected your inventory, configuration, deployed build, reachability or evidence. A catalog listing and a severity score do not establish exposure or compromise.
01 / Meaning
Why it matters
Published affected context helps an owner decide what evidence to gather. This report has not examined your application.
02 / Applicability
The affected context
Affected versions, configuration prerequisites and known exclusions are public. Confirm each one against the deployed service.
poweradmin/poweradmin
source listedECOSYSTEM: introduced 3.0.0; fixed 3.9.11
## 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
poweradmin/poweradmin
source listedECOSYSTEM: introduced 4.0.0; fixed 4.2.5
## 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
poweradmin/poweradmin
source listedECOSYSTEM: introduced 4.3.0; fixed 4.3.4
## 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
03 / Response
What to do next
- vendor patch
The original advisory lists fixed boundaries 3.9.11 for poweradmin/poweradmin. Confirm the publisher’s latest guidance.
Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system. GitHub Advisory Database via OSV
- vendor patch
The original advisory lists fixed boundaries 4.2.5 for poweradmin/poweradmin. Confirm the publisher’s latest guidance.
Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system. GitHub Advisory Database via OSV
- vendor patch
The original advisory lists fixed boundaries 4.3.4 for poweradmin/poweradmin. Confirm the publisher’s latest guidance.
Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system. GitHub Advisory Database via OSV
A fixed release is not deployment evidence.
Check current vendor support and compatibility. After making a change, verify the deployed build and relevant runtime conditions. Keep the evidence, owner and time. An updated lockfile alone does not prove what is running.
04 / Limits
What this report cannot establish
- Customer inventory, deployment, reachability and exploitation have not been inspected.
05 / Provenance
Sources you can inspect
Each assertion retains its source. Mirrored records may repeat one underlying publisher; additional links are not independent corroboration.
- GHSA-rm67-g9ch-vxff ↗
GitHub Advisory Database via OSV · vendor advisory
Observed . GitHub-origin advisory, CC-BY-4.0; OSV is an aggregate copy, not independent corroboration.
Public revision history
Only published revisions appear here. Routine fetches do not create a material-change event.
- Revision 1 ·
First indexed by Null; source disclosure date is shown separately.