GHSA-RM67-G9CH-VXFF

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

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:

• Repointing or corrupting other customers' / other departments' DNS records (integrity).
• Silently disabling records by setting disabled = 1 (availability).
• 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).

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.

GHSA-RM67-G9CH-VXFF has a CVSS score of 8.1 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.9.11, 4.2.5, 4.3.4); upgrading removes the vulnerable code path.

Kodem intelligence

Already deployed Kodem?

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.

1. What is GHSA-RM67-G9CH-VXFF? GHSA-RM67-G9CH-VXFF is a high-severity security vulnerability in poweradmin/poweradmin (composer), affecting versions >= 3.0.0, < 3.9.11. It is fixed in 3.9.11, 4.2.5, 4.3.4.
2. How severe is GHSA-RM67-G9CH-VXFF? GHSA-RM67-G9CH-VXFF has a CVSS score of 8.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of poweradmin/poweradmin are affected by GHSA-RM67-G9CH-VXFF? poweradmin/poweradmin (composer) versions >= 3.0.0, < 3.9.11 is affected.
4. Is there a fix for GHSA-RM67-G9CH-VXFF? Yes. GHSA-RM67-G9CH-VXFF is fixed in 3.9.11, 4.2.5, 4.3.4. Upgrade to this version or later.
5. Is GHSA-RM67-G9CH-VXFF exploitable, and should I be worried? Whether GHSA-RM67-G9CH-VXFF is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-RM67-G9CH-VXFF is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-RM67-G9CH-VXFF?
   • Upgrade poweradmin/poweradmin to 3.9.11 or later
   • Upgrade poweradmin/poweradmin to 4.2.5 or later
   • Upgrade poweradmin/poweradmin to 4.3.4 or later

Other vulnerabilities in poweradmin/poweradmin