{"items":[{"id":"NVI-00001852","kind":"vulnerability","title":"Poweradmin: Broken access control (IDOR): any zone owner can modify DNS records in zones they do not own","revision":1,"unknowns":["Customer inventory, deployment, reachability and exploitation have not been inspected."],"lifecycle":"active","identifiers":["GHSA-rm67-g9ch-vxff"],"plain_summary":"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.","review_status":"source_listed","control_topics":[],"public_actions":[{"summary":"The original advisory lists fixed boundaries 3.9.11 for poweradmin/poweradmin. Confirm the publisher’s latest guidance.","source_ids":["sr-02c60e61e4cad3adb109aa32f1e281bd"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null},{"summary":"The original advisory lists fixed boundaries 4.2.5 for poweradmin/poweradmin. Confirm the publisher’s latest guidance.","source_ids":["sr-02c60e61e4cad3adb109aa32f1e281bd"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null},{"summary":"The original advisory lists fixed boundaries 4.3.4 for poweradmin/poweradmin. Confirm the publisher’s latest guidance.","source_ids":["sr-02c60e61e4cad3adb109aa32f1e281bd"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null}],"schema_version":"1.1.0","source_metrics":[],"why_it_matters":"Published affected context helps an owner decide what evidence to gather. This report has not examined your application.","related_sources":[{"id":"sr-02c60e61e4cad3adb109aa32f1e281bd","url":"https://github.com/advisories/GHSA-rm67-g9ch-vxff","basis":"vendor_advisory","notes":"GitHub-origin advisory, CC-BY-4.0; OSV is an aggregate copy, not independent corroboration.","title":"GHSA-rm67-g9ch-vxff","publisher":"GitHub Advisory Database via OSV","observed_at":"2026-10-31T21:42:41.364Z"}],"affected_context":[{"certainty":"source_listed","source_ids":["sr-02c60e61e4cad3adb109aa32f1e281bd"],"technology":"poweradmin/poweradmin","known_exclusions":[],"conditions_summary":"## 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","public_affected_ranges":["ECOSYSTEM: introduced 3.0.0; fixed 3.9.11"]},{"certainty":"source_listed","source_ids":["sr-02c60e61e4cad3adb109aa32f1e281bd"],"technology":"poweradmin/poweradmin","known_exclusions":[],"conditions_summary":"## 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","public_affected_ranges":["ECOSYSTEM: introduced 4.0.0; fixed 4.2.5"]},{"certainty":"source_listed","source_ids":["sr-02c60e61e4cad3adb109aa32f1e281bd"],"technology":"poweradmin/poweradmin","known_exclusions":[],"conditions_summary":"## 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","public_affected_ranges":["ECOSYSTEM: introduced 4.3.0; fixed 4.3.4"]}],"null_published_at":"2026-10-31T21:53:28.052Z","source_updated_at":"2026-07-24T22:00:28.386Z","source_disclosed_at":"2026-07-24T21:55:15.000Z","is_synthetic_fixture":false,"null_last_reviewed_at":null,"public_change_summary":"First indexed by Null; source disclosure date is shown separately.","null_first_observed_at":"2026-10-31T21:42:41.364Z"}],"next_cursor":null,"snapshot_revision":"42594"}