Attack Chain

1. An attacker, authenticated with a low-privilege "Editor" account, owns at least one DNS zone (e.g., attacker.example, zone ID 3).
2. The attacker identifies a target DNS record in a zone they do not own (e.g., www.victim.example with record ID 5, residing in victim.example with zone ID 2).
3. The attacker navigates to their own zone's edit page (e.g., /zones/3/edit) and initiates a record save action using an intercepting proxy.
4. Within the POST /zones/3/edit request body, the attacker manipulates parameters, specifically setting record[5][rid]=5 (the victim's record ID) and record[5][zid]=3 (the attacker's legitimate zone ID).
5. The Poweradmin application performs an ownership check using record[5][zid]=3 from the request, which passes successfully due to the attacker's legitimate ownership of zone 3.
6. The application proceeds to modify the record using record[5][rid]=5 without verifying that this record (ID 5) actually belongs to zone ID 3, thus overwriting the victim's DNS record (e.g., changing www.victim.example content to 6.6.6.6).
7. The attacker successfully modifies a DNS record in a zone they are not authorized to access, demonstrating a bypass of intended access controls and potentially leading to DNS takeover.

Impact

Successful exploitation of this IDOR vulnerability allows an authenticated attacker to compromise the integrity and availability of DNS records across the entire Poweradmin installation. Attackers can repoint DNS records (e.g., pwned.attacker.example) to malicious infrastructure, corrupt existing records, or silently disable critical services by setting the disabled flag. In multi-tenant or shared hosting environments, this directly translates to cross-tenant DNS takeover, where one customer's records can be hijacked or disrupted by another using their attacker.example domain. This poses a significant threat to an organization's online presence, email delivery, and other services reliant on accurate DNS resolution, potentially leading to widespread service outages or redirection to phishing/malware sites. The attacker's own valid CSRF token and zone serial satisfy all form-level checks, making the malicious request appear legitimate to the application.

Recommendation

• Patch Poweradmin installations immediately to versions 3.9.11, 4.2.5, or 4.3.4 or later to address the vulnerability described in the GHSA-rm67-g9ch-vxff advisory.
• Implement server-side validation, as suggested in the GHSA-rm67-g9ch-vxff advisory, to ensure the record ID being modified truly belongs to the zone ID used for access checks.
• Review web server access logs for anomalous POST /zones/*/edit requests, paying attention to the context around the rid and zid parameters in the request body for evidence of the IDOR identified in the attack chain.