Poweradmin - CraftedSignal Threat Feed

Poweradmin OIDC `sub` Collation Bypass Leads to Account Takeover

hello@craftedsignal.io — Fri, 24 Jul 2026 22:02:03 +0000

A high-severity vulnerability has been identified in Poweradmin, an open-source web-based management tool for PowerDNS. This flaw, tracked in GHSA-cmwh-g2h8-c222, allows an unauthenticated attacker to bypass OIDC identity collation, leading to account takeover. The issue stems from Poweradmin's use of a case- and accent-insensitive MySQL collation (utf8mb4_unicode_ci) for storing and matching OIDC subject identifiers (oidc_subject). An attacker can create an OIDC account with a subject that is a collation variant of a legitimate victim's subject (e.g., victim-login vs. victím-login). When the attacker attempts to authenticate, Poweradmin's database lookup, performed under the weak collation, incorrectly matches the attacker's subject to the victim's existing user_id, granting the attacker an authenticated session to the victim's Poweradmin account. The vulnerability affects Poweradmin versions 4.1.0 through 4.2.4 and 4.3.0 through 4.3.3, and it has been fixed in versions 4.2.5, 4.3.4, and 4.4.0.

Attack Chain

A legitimate victim links their OIDC account with Poweradmin; Poweradmin stores the victim's OIDC sub (e.g., victim-login) in the oidc_user_links table with a utf8mb4_unicode_ci collation.
An attacker creates an OIDC account at the same OIDC provider with a sub identifier that is a collation variant of the victim's sub (e.g., victím-login), exploiting the accent-insensitive nature of the collation.
The attacker initiates an OIDC login to Poweradmin by accessing /oidc/login?provider=generic and authenticates with their attacker OIDC credentials (victím-login).
Poweradmin receives the attacker's OIDC sub (victím-login) from the OIDC provider's userinfo endpoint after a successful authorization code flow.
Poweradmin queries its oidc_user_links database table to find an existing user linked to the received oidc_subject and provider_id.
Due to the utf8mb4_unicode_ci collation used for oidc_subject, the database query interprets the attacker's sub (victím-login) as equal to the victim's sub (victim-login).
The database returns the user_id associated with the victim's account, and Poweradmin establishes an authenticated session for the attacker under the victim's identity, leading to account takeover.

Impact

Successful exploitation of this vulnerability allows an unauthenticated attacker, with control over an OIDC account that has a colliding subject identifier, to gain full access to a victim's Poweradmin account. This can result in unauthorized modification or deletion of DNS records, compromise of administrative settings, and complete control over the PowerDNS environment managed by Poweradmin. The attacker can achieve this without knowing or modifying the victim's password, leveraging only their own OIDC credentials and the database collation weakness. No specific victim counts or targeted sectors were provided, but any organization using affected Poweradmin versions with OIDC authentication is at risk.

Recommendation

Patch Poweradmin installations to versions 4.2.5, 4.3.4, or 4.4.0 immediately to address the OIDC sub collation bypass vulnerability.
As part of the upgrade process, execute the provided SQL update script located in the sql/ directory for your specific database to migrate the oidc_user_links table columns (oidc_subject, provider_id) to a binary or byte-preserving collation (e.g., utf8mb4_bin).
Review other identity and authorization lookups within your Poweradmin environment, specifically findUserByEmail(), findPermissionTemplateByName(), and findGroupByName(), to ensure they enforce byte-exact matching where security boundaries are involved.

Poweradmin API Privilege Escalation via User-Update Endpoint

hello@craftedsignal.io — Fri, 24 Jul 2026 21:58:37 +0000

A high-severity privilege escalation vulnerability (GHSA-h4hf-v6w5-897x) has been identified in Poweradmin, an open-source web-based management tool for PowerDNS. This flaw allows a non-administrative user with the user_edit_others permission to reset the password of any other user, including superuser accounts, through the REST API. This is due to a discrepancy where the API's user-update endpoint (PUT/PATCH /api/v2/users/{id} and its V1 equivalent) fails to enforce authorization checks present in the web interface. Specifically, the API lacks safeguards that prevent non-superusers from editing superuser accounts and from changing passwords without the user_passwd_edit_others permission. This vulnerability affects Poweradmin versions 4.0.0 through 4.2.4 and 4.3.0 through 4.3.3. Exploitation requires the REST API to be enabled and the existence of a delegated "user manager" role, which is common in many deployments for helpdesk or team lead functions. The result is a complete administrative account takeover with a single API request, allowing full control over DNS infrastructure.

Attack Chain

An administrator configures Poweradmin with the REST API enabled and establishes a delegated "user manager" role that grants user_edit_others permission (ID 57) but not user_is_ueberuser (ID 53) or user_passwd_edit_others (ID 58).
An attacker gains access to credentials for a user assigned to this "user manager" role.
The attacker generates an API key associated with their "user manager" account within Poweradmin.
The attacker crafts an HTTP PUT or PATCH request targeting the Poweradmin API's user-update endpoint, specifying the superuser's account ID (commonly 1) in the URL (e.g., PUT /api/v2/users/1).
The request body includes a JSON payload containing a new password for the targeted superuser account, such as {"password":"NewAdminPass1!"}.
Due to missing authorization logic in lib/Domain/Service/ApiPermissionService.php::canEditUser(), the API permits the non-superuser "user manager" to edit the superuser's account.
Subsequently, lib/Domain/Service/UserManagementService.php::updateUser() processes the request and writes the new password without verifying if the caller possesses user_passwd_edit_others permission.
The attacker then uses the newly set password to log into Poweradmin as the superuser, achieving full administrative control over the system and the underlying PowerDNS infrastructure.

Impact

This broken access control and privilege escalation issue (CWE-285, CWE-266) allows any authenticated non-admin user with user_edit_others permission to gain full administrative control over affected Poweradmin installations. This directly impacts any Poweradmin deployment where the REST API is enabled and a delegated user management role exists. Upon successful exploitation, the attacker can reset the superuser's password, log in as the administrator, and subsequently control all zones, records, users, and settings within Poweradmin. This effectively grants control over the organization's DNS data managed by PowerDNS, posing a critical risk to network infrastructure and potentially enabling further attacks like traffic redirection or denial of service. The severity is high due to the complete administrative takeover achievable with a single over-the-network request from a low-privilege authenticated position.

Recommendation

Patch Poweradmin installations immediately to a fixed version (Poweradmin 4.2.5 or 4.3.4, or later) to resolve the vulnerability described in GHSA-h4hf-v6w5-897x.
Deploy the Detect Poweradmin API User Password Update Attempt for Superuser Sigma rule to your SIEM to monitor for suspicious API calls targeting superuser accounts.
Review web server access logs for PUT or PATCH requests to /api/v[12]/users/1 by non-superuser accounts, especially those utilizing API keys, to identify potential exploitation attempts.
If web server logs capture request bodies, examine them for JSON payloads containing a "password" field during API user update calls.

Poweradmin: Broken Access Control (IDOR) Allows DNS Record Modification

hello@craftedsignal.io — Fri, 24 Jul 2026 21:57:43 +0000

A critical Insecure Direct Object Reference (IDOR) vulnerability (GHSA-rm67-g9ch-vxff) has been disclosed in Poweradmin, a web front-end for PowerDNS. Discovered by Saif Salah, this flaw allows any authenticated user possessing ownership of at least one DNS zone to arbitrarily modify, disable, or hijack DNS records in any other zone managed by the server, regardless of their legitimate access permissions. The vulnerability, present across Poweradmin versions prior to 3.9.11, 4.2.5, and 4.3.4, stems from a logical error in the RecordManager::editRecord() function. Access control checks are performed against an attacker-controlled zone ID, while the actual record modification is applied to a different, attacker-controlled record ID without verifying their association. This can lead to a full cross-tenant DNS takeover in shared or multi-tenant environments, posing significant risks to DNS integrity and service availability.

Attack Chain

An attacker, authenticated with a low-privilege "Editor" account, owns at least one DNS zone (e.g., attacker.example, zone ID 3).
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).
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.
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).
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.
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).
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.