high

GHSA-rm67-g9ch-vxff

Packagist · poweradmin/poweradmin

Summary

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

Severity
high
CVSS
8.1
CWE
CWE-284, CWE-639
Published
2026-07-24
Updated
2026-07-24

Advisory details

Affected software

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:

// 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:

$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):

Steps:

  1. 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.

  2. 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.

  3. Edit the record block in that request so it targets the victim's record while keeping your own zone id:

POST /zones/3/edit HTTP/1.1
Host: localhost:8080
Cookie: PHPSESSID=<your attacker session>
Content-Type: application/x-www-form-urlencoded

_token=<the valid token from step 2>&serial=<the valid serial from step 2>&commit=1
&record[5][rid]=5&record[5][zid]=3
&record[5][name]=pwned&record[5][type]=A&record[5][content]=6.6.6.6
&record[5][ttl]=3600&record[5][prio]=0

The 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).

  1. Send it. You get HTTP 200.

  2. Check the result. Record 5, which lives in the admin's zone, is now overwritten:

sqlite> SELECT id, domain_id, name, type, content FROM records WHERE id = 5;
5|2|pwned.attacker.example|A|6.6.6.6
Screenshot 2026-07-06 162351

It'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.

Two practical notes if you're reproducing this:

Impact

With one owned zone, an attacker can rewrite content, type, ttl and the disabled flag of any record anywhere in the installation. Concretely that means:

In 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.

The attacker's own CSRF token and own zone serial satisfy every form-level check, so nothing about the request looks abnormal to the app.

Suggested fix

Stop 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:

$details = $recordRepository->getRecordDetailsFromRecordId($record['rid']);
if ($details === null) {
    // record doesn't exist – reject
    return false;
}
$realZid = $details['zid'];
// use $realZid for verifyUserIsOwnerZoneId() and for zone-name normalization

Reject the edit if the record doesn't exist, and never let the client decide which zone a record "belongs" to.

Di

References

Related advisories

Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.

Check my repo

Summarize with AI

ChatGPTClaudePerplexity

Sources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.