Domain Registrar Security Review: Closing an Unauthenticated API Injection and a Registrar-Lock Bypass
Client: A domain name registrar and reseller platform (name withheld under client confidentiality)
13
Validated findings across app, API & infrastructure
6
High-severity issues confirmed exploitable
0
Critical findings — key domain-theft protections held
The challenge
This domain registrar operates a customer portal, DNS management tooling, and a reseller API consumed by downstream partner systems. Ahead of scaling its partner integrations, it engaged Eiferone for a full external security assessment.
The approach
Eiferone assessed the application layer, the reseller API, and supporting infrastructure through reconnaissance, automated identification, manual exploitation and validation, and risk impact analysis, aligned to OWASP WSTG, CVSS v3.1, and CWE.
What we found
Multiple systems across the environment were running PHP runtimes that had been unsupported for years, one for over a decade, and broadcasting their exact version to anyone who asked. The customer-facing site loaded a legacy JavaScript library configured to automatically execute scripts returned from remote calls, a setting that would turn even a minor future injection bug into full script execution in a visitor's browser. The reseller API, consumed by downstream partner systems, accepted unauthenticated requests and reflected user input directly into its XML responses without encoding it, letting an attacker inject fabricated status codes a partner's automated system might treat as genuine. Three separate DNS and forwarding-management endpoints processed state-changing requests over plain GET rather than POST, letting an attacker hijack a logged-in customer's domain configuration with nothing more than a link or a hidden image tag, no phishing site required. And the endpoint controlling a domain's registrar lock accepted a raw domain identifier from any authenticated customer without checking they actually owned it, letting one account lock or unlock a domain belonging to someone else. Medium and low findings covered outdated mail and web server software, a client-side-only cap on an automated lookup tool that the backend didn't enforce, and further DNS and TLS hardening gaps.
The outcome
Critically, Eiferone's testing confirmed that the page controlling the authorization code required for a full domain transfer remained properly access-controlled throughout, containing the blast radius of the other findings. The immediate roadmap covered output encoding on the reseller API, converting the CSRF-exposed endpoints to strict server-side POST handling with anti-CSRF tokens, adding object-level ownership checks to the lock and unlock endpoint, and a phased plan to retire the outdated PHP runtimes.